Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. EVC implements support for v2, and supports both v1 and v2 APIs in version 3.1. 
  2. EVC is upgraded to 3.1. At this point, both v1 and v2 APIs are supported by EVC, so existing EVE instances with 3.0 or below will continue to work with v1.
  3. EVE software adds support to switch to v2 APIs, with default choice as v1, in version 3.1.
  4. Some of the EVE instances are upgraded to 3.1, and configured to use v2 API. They will work too, since EVC supports v1 and v2 at this point. Any EVE-EVC integration issues can be debugged and fixed at this point.
  5. All the devices are upgraded to 3.1, and switched to v2 API
  6. EVC stops supporting v1 from 3.2
  7. EVC is upgraded to 3.2. This should not be a problem since all the devices are moved to v2 at this point
  8. EVE stops supporting v1, and makes v2 as the only supported API version, in 3.2
  9. EVE instances are upgraded to 3.2. 
  10. After this point, any EVE instance trying to go back to a version 3.1 are below(which use v1 API), will see failure, and come back to the current version. This is because the older version will try to talk v1 to EVC, which is discontinued, and hence EVE will timeout, declare the old image toxic and fallback to current version.

Certificate Rotation

If EVC decides to change the signing keys it is using, it can do the following steps:

  1. Create new private, public key
  2. Generate the new X.509 certificate signed by the intermediate CAs rooted to the root CA shared with the EVE.
  3. Make the new X.509 certificate available in the API to fetch EVC certificates
  4. Update the certificate identifier in the payload envelopes

Then,

  1.  EVE does a lookup for the certificate identifier in the envelope
  2. The lookup fails, and that triggers EVE to fetch EVC certificates again
  3. With this fetch, EVE now has the latest EVC certificate to verify the signature

Object Level Security

One of the issues discussed above was to secure the sensitive information in the payload from getting exposed in transit, due to termination of TLS at proxy server. To address this, sensitive parts of the configuration will be encrypted using a shared symmetric key. The details on how this shared symmetric key is arrived at, and how the encryption and decryption happen, can be found at Secure Storage of Sensitive Information on EVE

...

OrderAPI Version OperationTLS Client CertArgsResponseRequest Enveloped?Response Enveloped?Context of invocation Comments?
1edgeDevice/registerv1POSTonboarding certificateonboarding key, serial, device certstandard HTTP response codeNoNoinitial onboarding
1edgeDevice/registerv2POSTNoneonboarding key, serial, device certstandard HTTP response codeYes, signed by onboarding certificateNoinitial onboarding
2

edgeDevice/Certs

(new)

v1/v2GETNone. Preference is to use HTTP if proxy supports.NoneController Certs, and HTTP response codeNoNoat every boot, if device does not have any controller cert
3edgeDevice/configv1POSTdevice certificatedevice certificateDevice ConfigurationNoNoat boot time. When we act on PCR values, PCR Quote will have to be sent along with the config request
3edgeDevice/configv2POSTNonedevice certificateDevice ConfigurationYes, signed by device certificate, and contains device certificate Yes, signed by Controller Cert shared in Order 2at boot time. When we act on PCR values, PCR Quote will have to be sent along with the config request
4

edgeDevice/id/<uuid>/attest

Sub-type ATTEST_REQ_CERT

v2POSTNoneAdditional Certs created by Devicestandard HTTP response codeYes, signed by device certificate. Envelope has device UUIDNoat boot timeenvelope to have device UUID or truncated hash of device cert?
5

edgeDevice/id/<uuid>/attest

Sub-type

ATTEST_REQ_NONCE

v2POSTNone NoneNonceYes, signed by device certificate. Envelope has device UUIDYes, signed by Controller Cert shared in Order 2Precedes PCR Quote POSTenvelope to have device UUID or truncated hash of device cert?
6

edgeDevice/id/<uuid>/attest

Sub-type

ATTEST_REQ_QUOTE

v2POSTNoneNonce, PCR Quote. Quote is signed with restricting signing key from deviceAttestResult(pass, fail) along with standard HTTP response codeYes, signed by device certificate. Envelope has device UUIDYes, signed by Controller Cert shared in Order 2Precedes config requestenvelope to have device UUID or truncated hash of device cert?
7edgeDevice/configv1POSTdevice certificatedevice UUID, hash of current configDevice Configuration, sensitive data encrypted with shared symmetric keyNoNoWhen we act on PCR values, PCR Quote will have to be sent along with the config request
7edgeDevice/configv2POSTdevice certificatedevice UUID, hash of current configDevice Configuration, sensitive data encrypted with shared symmetric keyYes, signed by device certificate. Envelope has device UUIDYes, signed by Controller Cert shared in Order 2When we act on PCR values, PCR Quote will have to be sent along with the config requestenvelope to have device UUID or truncated hash of device cert?