...
With these steps, EVE and EVC are ready to sign and also validate the signature of the other party.
EVE-EVC communication with V2 APIs
EVE does the following whenever it does a POST to EVC's v2 API:
...
- 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 or 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.
...
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
Normative Reference of v2
...
APIs
This is a normative reference to the various EVC APIs, their v1/v2 differences, the payload fields, components of envelope etc.
| Order | API | Version | Operation | TLS Client Cert | Args | Response | Request Enveloped? | Response Enveloped? | Context of invocation |
|---|---|---|---|---|---|---|---|---|---|
| 1 | edgeDevice/register | v1 | POST | onboarding certificate | onboarding keyserial, soft serial, device cert | standard HTTP response code | No | No | initial onboarding |
| 1 | edgeDevice/register | v2 | POST | None | onboarding key, serial, soft 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 |
| 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 POST |
| 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 request |
| 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 request |
...