These are surprisingly deep questions about Intel SGX, so I've tried to give a good overview, covering the cryptographic and protocol level details to some degree of depth. Please ask followup questions if any of this is unclear! I've included a list of references and additional resources at the end.
All enclave data is transparently encrypted in memory. This is performed by the SGX Memory Encryption Engine (MEE). The MEE uses a complicated combination of Merkle trees, a tweaked version of AES Counter Mode, and a Carter-Wegman MAC construction. This uses a 128-bit confidentiality key, a 56-bit counter, a 128-bit integrity key (producing 56-bit MAC tags), and a 512-bit universal hash key (used in the MAC construction). These are generated at boot, placed in special MEE registers, and destroyed at system reset. The MEE operates on 512-bit cache lines, so each encryption takes four AES operations. (See [1, 2, 3] for more details.)
Each enclave has an enclave certificate, which contains its supposed measurement, a vendor ID, a product ID, a version number, and some enclave attributes.
When an enclave is set up (using the EADD/EEXTEND instructions), it takes a measurement of its contents by taking the SHA-256 hash of its memory pages. This is finalized at the point of initialization of the enclave (using the EINIT instruction, after having all initial memory contents copied into its enclave pages). This hash serves as the measurement of the enclave. This is similar to other remote attestation techniques.
An enclave gets a signed attestation for itself from a special Intel enclave called the Quoting Enclave using the local attestation process. First, the enclave requests a local attestation report using the EREPORT instruction. The CPU computes an AES128-CMAC tag on the enclave's measurement and certificate to create the report. The Quoting Enclave checks the MAC on the report and replaces it with a signature using the CPU's Attestation Key (which the Quoting Enclave has special permission to access). This signature uses the Intel Enhanced Privacy ID (EPID) scheme [6,7,8], which is a group signature scheme. This means that a valid signature proves that it was part of the group, but does not reveal which member it is for. Intel maintains the group keys that let it verify signatures. The signed attestation quote is returned to the enclave, which can use it to attest to the remote party.
This signed attestation quote is sent to the remote party. It attests to the enclave's certificate (which contains the enclave's measurement, product ID number, version number, vendor ID, and some enclave attributes). The remote party connects to the Intel Attestation Service to verify the signed attestation quote from the enclave.
Remote attestation uses a secret that Intel burns into the CPU at the time of manufacturing (the Provisioning Secret) and another secret burned into the CPU at boot time (the Sealing Secret). The Provisioning Secret is shared with Intel (and stored in an Intel database for the attestation service). The Sealing Secret is not accessible outside of the CPU.
The Attestation Key is given to the Provisioning Enclave, which uses the Provisioning key (derived from the Provisioning Secret) to prove to the Intel service that it is legitimate. The Attestation Key is sealed in storage using the Provisioning Sealing Key (which is derived from the Sealing Secret). The stored Attestation Key can be reused repeatedly without contacting Intel servers.
Interaction with Intel
An SGX enabled processor will do a one-time initialization that involves communicating with Intel attestation servers. See [1, 6, 7]. This initialization survives change-of-ownership as well.
An SGX enabled processor will contact Intel servers via the Provisioning Enclave in order to receive an Attestation Key. The Attestation Key is sealed and stored and can be repeatedly used to create attestations. Note that the Intel provisioning service can detect deprecated SGX versions and refuse to issue new attestation keys.
A remote party must connect to the Intel Attestation Service each time it wants to verify a signed attestation quote from an enclave.
For a very in-depth treatment of SGX, I recommend "Intel SGX Explained" . It gives an impressive amount of background into computer architecture, cryptography, low-level attacks, and other trusted computing hardware (which you can probably skip if you just want to read about SGX or are already familiar with those topics). This answer is largely a summary of their more in-depth explanations.
For more information about the MEE, I recommend  and .
Another good document, particularly if you are interested in current state-of-the-art in implementing secure services using SGX, is Jethro Beekman's dissertation on the subject . It also provides good background on SGX from a software implementer's perspective.
The Intel Resources Library  provides a number of documents, at various levels of detail, on SGX functionality and implementation.
-  "Intel SGX Explained", by Costan and Devadas. Cryptology ePrint Archive: Report 2016/086, https://eprint.iacr.org/2016/086
-  "A Memory Encryption Engine Suitable for General Purpose Processors", by Shay Gueron. Cryptology ePrint Archive: Report 2016/204, https://eprint.iacr.org/2016/204
-  "Presentation for Intel SGX: ISCA 2015". https://software.intel.com/sites/default/files/332680-001.pdf
-  "Improving Cloud Security using Secure Enclaves" by Jethro Beekman, https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-219.pdf
-  Intel SGX Resource Library https://software.intel.com/en-us/sgx/resource-library
-  "Intel Software Guard Extensions: EPID Provisioning and Attestation Services", by Johnson, Scarlata, Rozas, Brickell, and Mckeen. https://software.intel.com/en-us/blogs/2016/03/09/intel-sgx-epid-provisioning-and-attestation-services
-  "Innovative Technology for CPU Based Attestation and Sealing", by Anati, Gueron, Johnson, and Scarlata. https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealing
-  "Enhanced Privacy ID from bilinear pairing", by Ernie Brickell and Jiangtao Li. Cryptology ePrint Archive: Report 2009/095, https://eprint.iacr.org/2009/095