...
- EVC implements support for v2, and supports both v1 and v2 APIs in version 3.1.
- 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.
- EVE software adds support to switch to v2 APIs, with default choice as v1, in version 3.1.
- 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.
- All the devices are upgraded to 3.1, and switched to v2 API
- EVC stops supporting v1 from 3.2
- EVC is upgraded to 3.2. This should not be a problem since all the devices are moved to v2 at this point
- EVE stops supporting v1, and makes v2 as the only supported API version, in 3.2
- EVE instances are upgraded to 3.2.
- 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:
- Create new private, public key
- Generate the new X.509 certificate signed by the intermediate CAs rooted to the root CA shared with the EVE.
- Make the new X.509 certificate available in the API to fetch EVC certificates
- Update the certificate identifier in the payload envelopes
Then,
- EVE does a lookup for the certificate identifier in the envelope
- The lookup fails, and that triggers EVE to fetch EVC certificates again
- 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
...
| Order | API | Version | Operation | TLS Client Cert | Args | Response | Request Enveloped? | Response Enveloped? | Context of invocation Comments? | |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | edgeDevice/register | v1 | POST | onboarding certificate | onboarding key, serial, device cert | standard HTTP response code | No | No | initial onboarding | |
| 1 | edgeDevice/register | v2 | POST | None | onboarding key, serial, device cert | standard HTTP response code | Yes, signed by onboarding certificate | No | initial onboarding | |
| 2 | edgeDevice/Certs (new) | v1/v2 | GET | None. Preference is to use HTTP if proxy supports. | None | Controller Certs, and HTTP response code | No | No | at every boot, if device does not have any controller cert | |
| 3 | edgeDevice/config | v1 | POST | device certificate | device certificate | Device Configuration | No | No | at boot time. When we act on PCR values, PCR Quote will have to be sent along with the config request | |
| 3 | edgeDevice/config | v2 | POST | None | device certificate | Device Configuration | Yes, signed by device certificate, and contains device certificate | Yes, signed by Controller Cert shared in Order 2 | at 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 | v2 | POST | None | Additional Certs created by Device | standard HTTP response code | Yes, signed by device certificate. Envelope has device UUID | No | at boot time | envelope to have device UUID or truncated hash of device cert? |
| 5 | edgeDevice/id/<uuid>/attest Sub-type ATTEST_REQ_NONCE | v2 | POST | None | None | Nonce | Yes, signed by device certificate. Envelope has device UUID | Yes, signed by Controller Cert shared in Order 2 | Precedes PCR Quote POSTenvelope to have device UUID or truncated hash of device cert? | |
| 6 | edgeDevice/id/<uuid>/attest Sub-type ATTEST_REQ_QUOTE | v2 | POST | None | Nonce, PCR Quote. Quote is signed with restricting signing key from device | AttestResult(pass, fail) along with standard HTTP response code | Yes, signed by device certificate. Envelope has device UUID | Yes, signed by Controller Cert shared in Order 2 | Precedes config requestenvelope to have device UUID or truncated hash of device cert? | |
| 7 | edgeDevice/config | v1 | POST | device certificate | device UUID, hash of current config | Device Configuration, sensitive data encrypted with shared symmetric key | No | No | When we act on PCR values, PCR Quote will have to be sent along with the config request | |
| 7 | edgeDevice/config | v2 | POST | device certificate | device UUID, hash of current config | Device Configuration, sensitive data encrypted with shared symmetric key | Yes, signed by device certificate. Envelope has device UUID | Yes, signed by Controller Cert shared in Order 2 | When 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? |