Session Management

Serverless Containers accessing the KMS

When working with serverless, it may happen that the server is unexpectedly shut down (e.g. due to low traffic) or scaled up. When the serverless container is shut down and restarted, it loses all of its previous state, including all of its session keys. In the worst case, this would mean re-running the TLS protocol every few seconds, which is inefficient, but not the biggest concern. On the other hand, when a web server is scaled up to run multiple instances of it, a load balancing algorithm decides which web server to route the current request to. This means that the next message sent will not necessarily be processed by the same web server, which can happen as early as in the handshake. To avoid this problem, the TLS connection is usually terminated at the gateway. However, in the case of confidential Knative, this would mean that traffic from the gateway to the enclave would be unprotected. This section only applies to the Queue proxy and the Activator, as both are scalable. The actual SECS does not need session management, as it only has a TLS connection to the same Queue Proxy. For simplicity, the enclaved Queue Proxy and Activator are referred to in the following section as the Confidential Knative (cKnative) components.

From this follows that there is a need for a secure, persistent and shared storage between multiple instances of queue-proxies and activators. The solution presented in Secure Storage fits perfectly here. Due to the fact, that same instances share the same measurement, access to secrets is only granted to those enclaves with the right measurement. Thus, simulating a secure shared storage.

For this to work, it is important to use TLS 1.3 because it has a 1 round trip to create the master secret. Otherwise you will have the same problem as above, as the next message could reach a different enclave. After creating the master secret, the cKnative components store the master secret in the KMS via RA-TLS. The KMS then associates the stored secret with the measurements of the cKnative components, authorizes only instances of them to access it, and returns a session ID. This session ID can then be used in the TLS protocol to identify the session and is sent back to the client. The session ID is the index of the master secret within the KMS and is generated by the KMS to prevent duplicate session IDs. Now the TLS protocol can continue as usual. If any cKnative component is shut down after the handshake, or any ciphertext is forwarded to another cKnative component, the enclave establishes an RA-TLS connection to the KMS, provides the session ID, and can retrieve the stored master secret because it has the same measurement and is authorized to do so. In the TLS protocol, the client always sends the session ID so that the server can efficiently identify the session key (master secret) used. To maintain post-compromise security and forward secrecy, the KMS must delete the stored secrets after a period of 24 hours or less to terminate the session. The exact amount of time varies from application to application, depending on the sensitivity of the data being transmitted. Note that if a master secret is compromised, all captured network traffic of the associated session during that time period may be decrypted. The client must also delete its secret, but if the client is using a browser, it most likely cannot do this in the same time period because the frontend's code is not running all the time. To do this, it stores a timestamp with the master secret in its local memory. By keeping the time period for deleting keys constant within an application, this can be hard-coded and does not need to be stored additionally. Now, before sending any ciphertext, the client first checks to see if the key expiration time has expired. If either the client or the enclave has deleted the session key, the TLS handshake must be reestablished. Session management is used primarily for efficiency and is not strictly necessary for security. Therefore, session management is not implemented and is left for future work.