At Evervault, we have been running AWS Nitro Enclaves in production for almost three years. During this time, we have encountered some undocumented qu

How we built Enclaves: Resolving clock drift in Nitro Enclaves

submited by

Style Pass

2024-02-27 16:30:06

At Evervault, we have been running AWS Nitro Enclaves in production for almost three years. During this time, we have encountered some undocumented quirks, one of the most surprising being a noticeable clock drift in as little as a day from the enclave launch.

The first implementation of Nitro Enclaves at Evervault was our encryption engine, which performs non-time-sensitive tasks and is authenticated with internal services using mTLS with externally generated keys and certificates. The mTLS connection is also terminated on the host, meaning that the time used will be accurate due to the Amazon Time Sync. The app was also subject to regular deployments and security patches, and due to this, we did not observe clock drift before we began working on Enclaves.

In an early iteration of Enclaves (formally known as Cages), the data plane generated self-signed certificates with the enclave attestation document embedded in the SAN of the certificate. Attestation documents have a 3-hour validity period, so the certificate needed to be regenerated every three hours. As this happened within the enclave, the enclave system time was used when generating “not before” and “not after” values in the certificate.