SPIKE: Enable end-to-end TLS between AMT and RPS (via rpc-go)

[graikhel-intel]

Background

Today, rpc-go acts as a proxy between Intel AMT (local MEI/LMS flow) and RPS. In the current mode, a secure WebSocket connection between RPS and rpc-go is terminated at rpc-go, and then a separate TLS connection is established between rpc-go and AMT/LMS.

Solution

Implement an end-to-end TLS flow where feasible so the communication between AMT and RPS is protected without intermediate TLS termination at rpc-go.

Additional flow details

We can split the RPS provisioning flows into two buckets, based on whether rpc-go can use TLS to LMS in pre-provisioning.

Use the rpc-go driver call STATE_INDEPENDENCE_IsChangeToAMTEnabled to determine whether rpc-go can connect to LMS over TLS in the pre-provisioning mode (i.e., whether we can start with TLS immediately or we must start non-TLS and transition later).

Pre-provisioning to ACM or CCM

Flow A: TLS available in pre-provisioning (AMT >= 19)

1. rpc-go calls STATE_INDEPENDENCE_IsChangeToAMTEnabled and determines that TLS is available in pre-provisioning
2. rpc-go opens a TCP connection to LMS on localhost:16993 (TLS port). At this point, this is only a TCP socket; no TLS handshake is initiated by rpc-go
3. rpc-go sends a message to RPS with the current device state and indicates it is ready to start receiving tunneled TLS bytes. Links to the current message structure https://github.com/device-management-toolkit/rps/blob/main/src/models/RCS.Config.ts#L206 and https://github.com/device-management-toolkit/rps/blob/main/src/models/RCS.Config.ts#L217
4. RPS initiates TLS client handshake toward AMT and sends the generated TLS handshake bytes to rpc-go
5. AMT (acting as the TLS server) responds with TLS handshake bytes, including its ODCA certificate chain, via LMS
6. rpc-go forwards the TLS handshake bytes unchanged to LMS over the TCP connection to port 16993
7. AMT (acting as the TLS server) responds with TLS handshake bytes, including its ODCA certificate chain, via LMS
8. rpc-go forwards the TLS handshake bytes received from LMS back to RPS without modification
9. RPS validates the ODCA certificate chain presented by AMT and completes the TLS handshake end-to-end with AMT
10. After the end-to-end TLS tunnel is established, RPS sends the required WSMAN messages to activate AMT to CCM
11. Once activated in CCM, AMT uses its default self-signed certificate. We need to replace that with a DMT-generated self-signed certificate
12. During DMT self-signed certificate generation, capture the public key hash (for certificate pinning) and store it in the database
13. Enable the DMT self-signed certificate into AMT (putLocalTLSData and putRemoteTLSData functions in tls.ts), so future TLS sessions can be pinned/validated using the stored public key hash
14. Perform Upgrade to ACM after this step, and then continue with the rest of the provisioning workflow (network settings, cira etc.)#### Flow B: TLS not available in pre-provisioning (AMT <= 18)

Activate to CCM, Enable TLS, and then transition to TLS

• rpc-go connects to LMS in non-TLS mode (port 16992).
• rpc-go activates AMT to CCM.
• rpc-go configures Self-signed Certificate (certs and configuration) needed for the TLS session.
• rpc-go closes the non-TLS connection.
• rpc-go starts a new TLS connection to LMS (port 16993).
• rpc-go now forwards raw TLS stream bytes between AMT/LMS and RPS (same as Flow A from this point onward).

Not end-to-end from the very first byte, but the steady-state provisioning channel becomes end-to-end TLS once TLS is configured and the TLS session is established.

[sudhir-intc]

Expectation is that this feature need to be provided with LMS enabled.