Coordinator API - allow updating mrenclave key

[fnerdman]

Use case

If the coordinator verifies a marble via the mrenclave instead of the mrsigner, no update mechanism exists yet. The coordinator needs to be reinitialized.

Describe your solution

allow mrenclave key updates, add these to the update log

Additional context

• Some use cases might exist, where marble secrets should be passed to the next mrenclave. Other use cases might want any secrets generated for marbles with the older mrenclave to be discarded.

[daniel-weisse]

Hi @lead4good ,
is updating mrenclave a requirement for your use case, or can this be solved by using mrsigner instead?

If only mrenclave updates are required, it shouldn't be too difficult to implement.
If however, you already see the need for updating other parts of the manifest that are currently not available (Marbles, Users, etc.), we might want to discuss changing the way updates work completely.
First thoughts include deploying an entire new manifest on top of the old one, or selectively adding, or removing, entries to any part of the manifest.

[fnerdman]

@brenzi @mullefel @daniel-weisse
Only mrenclave updates are required for Integritees use case. However it is likely that in some situations secrets should be passed on to the new enclave version, while other situations might strictly forbid this.

[m1ghtym0]

@lead4good @brenzi @mullefel
Okay, we can allow updating the mrenclave. To that end, you'll need to extend the update routine for the mrenclave field in the manifest.

Regarding the secret management. Currently, a secret can only have one "version" of that secret.
When updating a secret it will be updated globally for all Marbles.
However, obtaining a new secret version requires restarting this Marble, which means by updating the mrenclave of the Marbles' package, you can make sure only new versions of that Marble will have access to the new version of that secret.
At the same time, that means the secret is updated for all other applications in your deployment. Depending on your use-case you need to work with multiple secrets or we'll need to extend this functionality as well at one point.

[m1ghtym0]

@lead4good Would a simple updateability of mrenclave be sufficient for your use-case with the current behavior of secret updates?

[fnerdman]

@m1ghtym0
Let's try to use an example to see whether that fits our use case.
There's a gramine application that uses a marblerun provided secret to encrypt its state as protected files. An update of that application needs to be rolled out, verification of that update is done via mrenclave.

From what I understand, updating the mrenclave would change the "version" of the protected files key secret. That would mean, the updated enclave would not be able to decrypt encrypted state stored by previous enclaves with an out of date mrenclave? Or can we access older versions of the secret as well? In that case, whatever had been stored and encrypted with the old version would need to be converted to that new key. This could possibly be detected as part of a startup routine.

In general it makes a lot of sense to shield the confidentiality of newer enclaves by distributing different secret versions, it just needs to be clear how to migrate from one version to the other while maintaining the old state.

[m1ghtym0]

@lead4good If you set the protected files key secret as shared. Newer versions of the gramine enclave will get the same secret and be able to decrypt the old state (taken from the nginx gramine example manifest:

      "ProtectedFilesKey": {
          "Type": "symmetric-key",
          "Size": 128,
          "Shared": true
      }

That also means all instances of this Marble will be able to decrypt each other's state because they share the same encryption key. Further, instances of the old Marble version will be able to decrypt the state of newer versions.

[m1ghtym0]

@lead4good Is this still a feature that you need or are actively working on?

[fnerdman]

@m1ghtym0 Integritee is still working on the "Attesteer" project which brought up this issue. However priority is concentrated else where currently.
@Niederb will continue work on the Attesteer and will take over from here.