Scrappy: SeCure Rate Assuring Protocol with PrivacY

TL;DR

Scrappy tackles the privacy-preserving rate-limiting problem by combining Direct Anonymous Attestation (DAA) with hardware security devices to produce unforgeable, unlinkable rate-assuring proofs within server-defined time windows $t$ and basenames $bsn$. By binding $t$ to a signer’s pseudonym and leveraging a log-based verifier sign-off, Scrappy achieves robust rate-limiting without revealing user identities, and remains resilient even if a device is compromised. The authors implement PoCs on TPM, hardware tokens, and smartphones, and demonstrate favorable latency and bandwidth characteristics alongside a thorough security evaluation that protects against forgery, tracking, and credential leakage. The work offers practical deployment guidance, analyzes usability and scalability, and outlines future directions such as broader hardware support and optimized deployment models for real-world adoption.

Abstract

Preventing abusive activities caused by adversaries accessing online services at a rate exceeding that expected by websites has become an ever-increasing problem. CAPTCHAs and SMS authentication are widely used to provide a solution by implementing rate limiting, although they are becoming less effective, and some are considered privacy-invasive. In light of this, many studies have proposed better rate-limiting systems that protect the privacy of legitimate users while blocking malicious actors. However, they suffer from one or more shortcomings: (1) assume trust in the underlying hardware and (2) are vulnerable to side-channel attacks. Motivated by the aforementioned issues, this paper proposes Scrappy: SeCure Rate Assuring Protocol with PrivacY. Scrappy allows clients to generate unforgeable yet unlinkable rate-assuring proofs, which provides the server with cryptographic guarantees that the client is not misbehaving. We design Scrappy using a combination of DAA and hardware security devices. Scrappy is implemented over three types of devices, including one that can immediately be deployed in the real world. Our baseline evaluation shows that the end-to-end latency of Scrappy is minimal, taking only 0.32 seconds, and uses only 679 bytes of bandwidth when transferring necessary data. We also conduct an extensive security evaluation, showing that the rate-limiting capability of Scrappy is unaffected even if the hardware security device is compromised.

Figures (5)

• Figure 1: Pseudonymity and Unlinkability of DAA
• Figure 2: How periodic k-TAA works.
• Figure 3: Initialization Phase of Scrappy protocol. $Enc_{k}(m)$ and $Dec_{k}(c)$ denotes a cryptographic encryption/decryption operation over $m$/$c$ using key $k$, respectively.
• Figure 4: Proof Generation and Verification Phases of Scrappy protocol. $DAA\_Sign()$ and $DAA\_Verify()$ are the DAA-specific operations described in Section \ref{['sec:background:daa']}.
• Figure 5: Implementation of signer-side components and their relationship.