Investigate potential generic timing side channel defenses

[cr-tk]

Under some circumstances, an attacker near or on the enclave host system may hypothetically be able to leverage some observable timing behavior of QOS enclave responses to extract sensitive information from the enclave system.

This is a general attack concern and not about a single specific known scenario or bug.

The situation may also involve

• crafted requests
• unintended bugs in the QOS system code or Pivot App
  • specifically, non-constant time code
• additional actions by the attacker to amplify the side channel, for example by putting load on either the host system or some other subsystem
• repeated actions against the same or against different enclaves

We should investigate typical system timing behavior, for example the latency and jitter for host-to-enclave communication that are observed under various conditions, to understand the relevance and scale of this general attack topic.

A hypothetical and untested mitigation approach could involve adding some random, unpredictable and bounded amount of delay to the enclave operation before sending observable responses, which may help to reduce the visibility of any timing-related issues. However, please note that this is a limited (weak?) defense that requires a complicated tradeoff with performance costs.

This topic was discussed in an internal chat channel on 11/23/2022.

Relevant ticket: #73.