Chaincode enclave / tlcc binding.

[mbrandenburger]

When a new chaincode enclave spawns it binds itself to a given tlcc enclave using local attestation. Typically, this includes a key exchange to protect the communication between the chaincode enclave and tlcc later.

However, the current code base has hardcoded shared key. Attestation and key exchange needs a revision.

Steps

• [x] Design of API and high-level architecture
• [ ] Library implementation
  • [ ] quick'n'dirty mock version
  • [ ] secure version
• [ ] Library test-cases
• [ ] Library integration
  • [ ] Session setup
  • from a staging perspective, we might "leak" the key here and stuff it into the place of the currently hard-coded (global) key [note this will prevent concurrent chaincodes with the session lifetime as defined in the UMLs ...)
  • [ ] Session request handling

See #410 and #420 for related bigger context.

[g2flyer]

Potentially we might eventually share the TLCC with multiple machines (e.g., VCA) to scale in which case we might also look at RA-TLS for this ..