...
- From EVC perspective, identifying an EVE instance with the incoming X.509 client certificate will not work, since the client certificate may not be from the actual client anymore (instead it is from the proxy server). Or in case of load-balancing proxies, EVC might not have access to any client certificate.
- From EVE perspective, using existing root CA to verify EVC identity will not work, as the incoming X.509 certificate from EVC may not be from the actual EVC server anymore (instead it is from the proxy server)
- Since proxy is terminating TLS and re-opening TLS on the other segment, there is a possibility of payload getting modified in the middle. Without any mechanisms to detect this, this can compromise integrity of EVE-EVC communication channel
- Since proxy can inspect the TLS payload in clear text, sensitive parts of payloads(like access credentials, keys etc) should be protected from getting exposed in transit.
Overview
Therefore, to enable EVE connectivity in such environments where proxy is used, following mechanism is used.
...
- EVE uses its device private key to sign the payload. The device certificate carries the public key. So EVC can validate the signature using device certificate
- EVC uses private key of its choice, makes the corresponding certificate available for download by anyone in the Internet. EVC signs using its private key, and EVE uses the published certificate to validate the signature
- The certificates themselves are exchanged using secure transactions. (please see "Provisioning" section below)
- As long as these EVE and EVC private keys are protected at their endpoints, signatures can't be forged in transit
Provisioning of X.509 Certificates for Envelope Verification
To use payload envelopes, both EVE and EVC need to know the certificates of the other party, before they can start sending payloads with envelopes carrying signatures of the payload. This is how they are provisioned:
...
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 | 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 POST | envelope 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 request | envelope 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 request | envelope to have device UUID or truncated hash of device cert? |