Protocol for FPC 1.x with multiple enclaves and single enclave endorsement policy

[g2flyer]

Is your feature request related to a problem? Please describe.

Our current protocols (in docs/design/fabric-v2+) currently support multiple per-chaincode enclaves only, either via single enclave endorsers (#274) or multi-enclave endorsers (#275) for FPC, but not FPC Lite.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[g2flyer]

Some initial thoughts/proposal

Challenges The challenge of key-distribution with FPC Lite is that an exporting enclave cannot asses whether an export is appropriate or not by consulting ercc (or alike) and hence can unavoidably^1 be tricked to leak secrets to un-approved entities. However, as long as these secrets are not yet used, all exports are accountable and there is a point in time where you are sure there is no further export, this shouldn't be an issue: users simply would not use a contract in such cases.

This will restrict key-distribution to initial setup. However, i think that should be ok for a start and already addresses one big drawback of a single enclave: The host of this enclave can decide to stop a chaincode whenever he doesn't like the state, making it intrinsically unfair. (You might handle it by putting some punishment on the host but that of course might now be too harsh on the host, e.g., when the chip failed.)

Proposal As i realized, above also can be realized very easy in our design with only minimal changes:

• state

  • ecc enclave gets two additional attested attributes
    • isFpcLite bool Denotes that it runs FPC lite variant (I should have done that already previously when doing the FPC Lite pass on the pumls ..)
    • keyGenerator bool denotes it is the key generator, not really needed as this is also implicitly clear from ERCC as the guy to registerCCkeys,
  • ecc also has an (enclave-life-time) ephemeral state
    • distributingKeys bool this would be always be initialized to false when enclave is created, would be set to true when generateCCKeys is called (and succeeds) and to false when (a new function) endKeyDist is called (or when implicitly when the enclave dies/is terminated)

• protobuf/messages

  • there is a new flow 'endKeyDist' flow from admin to initial key-generating enclave, back to admin and then to ERCC. The message which is registered in ERCC should link (directly or indirectly) to the chaincode EK (and hence also state encryption key as they should be generated together in registerCCkeys) and the list of enclaves to which keys were exported and should be signed by the key-generating enclave.

• behaviour

  • ecc_enclave

    • exportCCkeysis operational/activated either
      • if not isFpcLite
      • or
        • if keyGenerator=true, i.e., in enclave which generated key via generateCCkeys
        • and keyDistributingKeys=true (i.e., only until first (and only) successfull endKeyDist invocation for a particular generateCCkeys
      • if not, a failure is returned
    • endKeyDist is operational/activated only
      • if keyGenerator=true & keyDistributingKeys=true
    • note that given the ephemeral nature of distributingKeys, the sequence of generateCCKeys, [exportCCkeys]*, endKeyDist must happen in same enclave instance and hence an endKeyDist will capture all exports

  • ercc

    • accepts exportCCkey response only if referenced enclave_ids are properly registered with chaincode and no endKeyDist message has been received yet for that chaincode.
    • accepts endKeyDist response only if referenced enclave_ids are propoerly registered as well as referenced chaincode EK matches the registered one.
    • QueryChaincodeEncryptionKey is operational/activated only if
      • either there is a chaincode encryption key registered by an enclave where (attested) isFpcLite is false
      • or a correct endKeyDist has been received (this would remove the requirements for the clients to check).
      • alternatively, could also always return key be additionally provide a flag whether keydist is finished or not (clients, though, should only start doing chaincode interactsion only after endKeyDist has happened as only then it is clear that only a fixed accountable set of appropriate enclaves has received the key

^1: at least not requiring some additional external machinery which boils down to a proof of publication, in which case we probably would better build a complete TL-full variant based on this?

[g2flyer]

btw: With externalized validation we have to be quite careful when going to support more than one enclave: Our __invoke query also has from a fabric perspective a valid R/W set and hence must not be allowed to succeed when run as an invoke (as nobody would have verified the enclave signatures)! With designated enclave policy of FPC 1.0, this it is a non-issue as you wouldn't get enough fabric endorsements. Without derandomized encryption, it probably should also be ok for #274 (as the R/W sets wouldn't agree) but once we would add that to get the ground for #275, this becomes an issue!