Further communication between enclaves after local attestation

I've been reading the following sample code which demonstrates the usage of local attestation: [here](https://github.com/apache/incubator-teaclave-sgx-sdk/tree/master/samplecode/localattestation)

In this example, enclaves communicate with each other through a series of `ECALLSs` and `OCALLs`. In doing this they can send and receive messages that are necessary to establish a secured connection. The result is a shared ECDH secret key to be used for future communication.

_How can I use this shared secret to continue communicating between enclaves 1 and 2?_

[This function](https://github.com/apache/incubator-teaclave-sgx-sdk/blob/master/samplecode/localattestation/attestation/src/func.rs#L66-L120), invoked from enclave 1, eventually establishes a secure connection after [processing msg3](https://github.com/apache/incubator-teaclave-sgx-sdk/blob/master/samplecode/localattestation/attestation/src/func.rs#L106). As a result of processing msg3, we obtain the [sgx_align_key_128bit_t](https://github.com/apache/incubator-teaclave-sgx-sdk/blob/master/samplecode/localattestation/attestation/src/func.rs#L70). My guess is that this is the symmetric key (can't find documentation on this).

**Questions:**
- To send further secure messages between the enclaves, does the `sgx_align_key_128bit_t` key need to be sealed to the enclave?
For example, You would seal in [create_session](https://github.com/apache/incubator-teaclave-sgx-sdk/blob/master/samplecode/localattestation/attestation/src/func.rs#L66-L120) for enclave 1 and in [exchange_report_safe](https://github.com/apache/incubator-teaclave-sgx-sdk/blob/master/samplecode/localattestation/attestation/src/func.rs#L159-L190) for enclave 2.
- Does the encrypting of messages need to be performed manually? Does the SDK provide some higher level APIs of this in action?
- I'd imagine the model for further communication will still follow the IPC pattern that was used for establishing the connection?

I noticed that in the [developer reference for linux](https://01.org/sites/default/files/documentation/intel_sgx_sdk_developer_reference_for_linux_os_pdf.pdf) it mentions:

> **Secret Message Exchange and Enclave to Enclave Call**
> The following figure illustrates the message exchange between two enclaves.
> After the establishment of the protected channel, session keys are used to
> encrypt the payload in the message(s) being exchanged between the source
> and destination enclaves. The sample code implements interfaces to encrypt
> the payload of the message. The sample code also shows the implementation
> of an enclave calling a function from another enclave. Call type, target function
> ID, total input parameter length and input parameters are encapsulated in the
> payload of the secret message sent from the caller (source) Enclave and the
> callee (destination) enclave. As one enclave cannot access memory of another
> enclave, all input and output parameters, including data indirectly referenced
> by a parameter needs to be marshaled across the two enclaves. The sample
> code uses Intel(R) SGX SDK trusted cryptographic library to encrypt the payload of the message. Through such encryption, message exchange is just the
> secret and in case of the enclave to enclave call is the marshaled destination
> enclave’s function id, total parameter length and all the parameters. The destination enclave decrypts the payload and calls the appropriate function. The
> results of the function call are encrypted using the session keys and sent back
> to the source enclave.

This suggests that their sample does provide this functionality.

@dingelish fyi

Start with samplecode/localattestation/attestation/src/func.rs, especially create_session and exchange_report_safe, and compare the message flow with the cited Intel SGX Developer Reference. Determine whether the sample or SDK documents session-key persistence, payload encryption, and continued enclave-to-enclave IPC; done means the supported procedure and relevant APIs are clearly documented.

Written by the indexing model from the issue text.