Groundhog: A Restart-Based Systems Framework for Increasing Availability in Threshold Cryptosystems

Threshold cryptosystems (TCs), developed to eliminate single points of failure in applications such as key management-as-a-service, signature schemes, encrypted data storage and even blockchain applications, rely on the assumption that an adversary does not corrupt more than a fixed number of nodes in a network. This assumption, once broken, can lead to the entire system being compromised. In this paper, we present a systems-level solution, viz., a reboot-based framework, Groundhog, that adds a layer of resiliency on top of threshold cryptosystems (as well as others); our framework ensures the system can be protected against malicious (mobile) adversaries that can corrupt up all but one device in the network. Groundhog ensures that a sufficient number of honest devices is always available to ensure the availability of the entire system. Our framework is general-izable to multiple threshold cryptosystems - we demonstrate this by integrating it with two well-known TC protocols - the Distributed Symmetric key Encryption system (DiSE) and the Boneh, Lynn and Shacham Distributed Signatures (BLS) system. In fact, Groundhog may have applicability in systems beyond those based on threshold cryptography - we demonstrate this on a simpler cryptographic protocol that we developed named PassAround¹¹In fact, this protocol was suggested by a USENIX Security reviewer that we then refined, implemented and evaluated in conjunction with Groundhog (see §6). . We developed a (generalizable) container-based framework that can be used to combine Groundhog (and its guarantees) with cryptographic protocols and evaluated our system using, ($a$) case studies of real world attacks as well as ($b$) extensive measurements by implementing the aforementioned DiSE, BLS and PassAround protocols on Groundhog. We show that Groundhog is able to guarantee high availability with minimal overheads (less than 7%). In some instances, Groundhog actually improves the performance of the TC schemes!²²While it seems counter-intuitive, we explain the reasoning in §5.