ADAM-CS: Advanced Asynchronous Monotonic Counter Service

Trusted execution environments (TEEs) offer the technological breakthrough to allow several applications to be deployed and executed over untrusted public cloud environments. Although TEEs (e. g., Intel SGX, ARM TrustZone, AMD SEV) provide several mechanisms to ensure confidentiality and integrity of data and code, they do not offer freshness out of the box, a critical aspect yet often overlooked, for instance, to protect against rollback attacks. Monotonic counters are a popular way to detect rollbacks, as their counter values cannot be decremented. However, counter increments are slow (i.e., 10^th of milliseconds), making their use impractical for distributed services and applications processing thousands of transactions simultaneously, for which an order of magnitude improvement is needed. ADAM-CS is an asynchronous monotonic counter service to protect such high-traffic applications against rollback attacks. Leveraging a set of distributed monotonic counters and specific algorithms, ADAM-CS minimizes the maximum vulnerability window (MVW), i.e., the amount of transactions an adversary could successfully rollback. Thanks to its asynchronous nature, ADAM-CS supports thousands of increments per second without introducing additional latency in the transactions performed by applications. Our measurements indicate that we can keep the MVW well below 10ms while supporting a throughput of more than 21K requests/s when using eight counters.

I. Introduction

Trusted execution environments (TEEs), ., Intel SGX [1],[2], give developers a set of hardware tools to protect their applications from various threats against the confidentiality and integrity of their data and code. TEEs allow developers to deploy and run systems in untrusted environments, such as public clouds, tolerating strong adversarial models under minimal trust constraints. Developers only need to trust the processor manufacturers. Unfortunately, TEEs do not protect against rollback attacks, in which an attacker tries to rollback an application state from a previous state to gain some benefits. Examples of such attacks include using already-expired software licenses ., version downgrade attacks), undoing certain transactions, or revert to old software versions to exploit known bugs [3]–[5]. While some solutions exist to protect TEEs against rollbacks [6],[7], they present a few drawbacks. LCM [7] relies on clients to ensure state continuity. Rote [6] assumes that at least one replica survives power outages to maintain the counter value.