Using Range-Revocable Pseudonyms to Provide Backward Unlinkability in the Edge

In this paper we propose a novel abstraction that we have named Range-Revocable Pseudonyms (RRPs). RRPs are a new class of pseudonyms whose validity can be revoked for any time-range within its original validity period. The key feature of RRPs is that the information provided to revoke a pseudonym for a given time-range cannot be linked with the information provided when using the pseudonym outside the revoked range. We provide an algorithm to implement RRPs using efficient cryptographic primitives where the space complexity of the pseudonym is constant, regardless of the granularity of the revocation range, and the space complexity of the revocation information only grows logarithmically with the granularity; this makes the use of RRPs far more efficient than the use of many short-lived pseudonyms. We have used RRPs to design EDGAR, an access control system for VANET scenarios that offers backward unlinkability. The experimental evaluation of EDGAR shows that, when using RRPs, the revocation can be performed efficiently (even when using time slots as small as 1 second) and that users can authenticate with low latency (0.5-3.5ms ).

*This is the extended version of a paper presented in CCS 2023 [28].This version includes an additional appendix with a more detailed proof of correctness and a complete workflow of all the operations discussed in the paper.Please, cite the CCS version instead of this one.

INTRODUCTION
Anonymous authentication offers both accountability and privacy, protecting clients from curious application providers while ensuring that only authorized participants are able to use the application [56,60,89,97].The number and relevance of applications that require anonymous authentication are increasing.Examples include crowdsensing [48,81,84,96] and Vehicular Networks (VANETs) [10,47,90], where clients voluntarily share information about their environment for the common good.Client authentication is a crucial mechanism to provide accountability for malicious and erroneous activity, ensuring the reliability of these applications [48,88].Unfortunately, authentication can compromise user privacy, as it may be associated with sensitive information, such as location [84].This is exacerbated by the fact that, in most of these applications, clients are mobile and may need to authenticate frequently, e.g., when they move to the range of a different base station or cell.Multiple authentications may be linked to extract additional information such as daily routines [48] or health status [64] for financial gain [6,23,63,72,73,102].Anonymous authentication can be achieved using Group Signatures (GS) schemes [13,22,96] or pseudonym certificates [21,67].

arXiv:2308.03402v1 [cs.CR] 7 Aug 2023
A challenging task in this context is to support revocation without violating privacy.Revocation aims to prevent some clients from further authenticating in the system.Client revocation may be required in the event of credential misuse, sensor malfunctioning, change in client privileges, stolen secret keys, or when a client leaves voluntarily.Client revocation can be implemented in different ways.We distinguish two main classes of revocation strategies, namely, global client revocation and verifier local revocation.
Strategies based on global client revocation require all clients to obtain new credentials (or update their credentials) every time a single client is revoked.Examples of this strategy include Ateniese et al. [5] (where the group public key is renewed at each revocation) and Ohara et al. [82] (where a small public membership message is broadcast at each revocation).These approaches make revocation very onerous in scenarios with many clients (e.g., consider vehicle numbers in VANETS) and impractical in mobile settings, where clients may become temporarily disconnected from the network.
Strategies based on Verifier Local Revocation (VLR) [13,16] do not require that all clients are contacted when a given client is revoked.Instead, only the nodes that perform authentication (often called the signature verifiers) have to be informed about the revoked clients [2,56,59,93,96,97].In systems that use pseudonyms, this involves sending to the verifiers a Certificate Revocation List (CRL) with the pseudonyms of the revoked client.In systems based on group signatures, this involves sending a cryptographic token that can be used to trace the digital signatures of the revoked client.
A problem with both approaches is that, if one or more credentials have been used before revocation, an attacker can cross-check the information used for revocation with the information collected when those pseudonyms were used to break the privacy of the client.Ideally, client revocation should not allow linking credentials that have been used prior to the revocation, a property known as Backward Unlinkability (BU) [49,56,60,76].Previous strategies to provide BU assign credentials that are valid only during a given time slot of a certain duration [49,60,89,96].Then, when a client is revoked, only the credentials for future time slots are revoked and no information is disclosed regarding credentials used prior to revocation.One can divide these recent strategies as GS with time-bounded keys [24,39] or pseudonyms with time slots [49,60].However, these schemes require the use of revocation lists whose size grows linearly with the number of time slots which, in practice, preclude the use of fine-grain time slots.
Revoking only the credentials for future time avoids backward linkability but, unfortunately, if time slots are large, it may be unacceptable to let revoked clients continue accessing resources until the current slot expires.For this reason, many systems immediately revoke the credentials for the current time slot, at the expense of exposing the client's privacy during that period [49,56,60,76].Our new class of pseudonyms supports efficient revocation even when fine-grain time slots are used, avoiding this dilemma.
This paper contributes to designing anonymous authentication systems for edge computing scenarios, like VANETs, that offer revocation and BU.We make two key contributions in this context: Contribution 1: We propose a novel abstraction named Range-Revocable Pseudonyms (RRPs).RRPs are pseudonyms that can be revoked for any time-range within their original validity period.
Clients hold a number of RRPs that is proportional to the number of authentication actions they need to perform, regardless of the granularity of the linkability window.Each RRP should be used at most once during its lifetime.In runtime, the RRP can be used to generate a capability that is only valid for the specific time slot where the RRP is being used.The key feature of RRPs is that the information provided to revoke a pseudonym for a given time-range cannot be linked with the information provided when using the pseudonym outside the revoked range.In particular, if a pseudonym is revoked at some point in time, it is impossible for an attacker to find out if that pseudonym has been used before that time.We provide an algorithm to implement RRPs where the space complexity of the pseudonym is constant, regardless of the granularity of the revocation range, and the space complexity of the revocation information only grows logarithmically with the granularity; this supports the use of fine-grain slots and makes the use of RRPs far more efficient than the use of many short-lived pseudonyms.We show that RRPs can be used to solve efficiently the BU problem for anonymous authentication.

Contribution 2:
We propose an access control system for VANET scenarios [10,47,90] that uses RRPs to offer BU.Our access control system, named EDGAR, illustrates how one can leverage RRPs to enforce authentication and revocation.In EDGAR, we deploy Pseudonym Manager (PM) servers that run on the edge of the network, serving clients with new RRPs.Since a PM server holds sensitive information, and the edge infrastructure in VANETS is known to be exposed to attacks [75,108], we have designed the PM server to be executed with the support of a Trust Execution Environment (TEE), such as Intel SGX enclaves [27,70,80].This allows the server to provide new RRPs to clients without disclosing their identities, even if the untrusted environment is compromised.
EDGAR paves the way for arbitrarily small time slots with minimal overhead.Consider a client who during the day goes to the hospital and before that to a nearby shop.When using EDGAR, clients only need a number of pseudonyms proportional to the number of resources they need to access (in this example, 2 resources), and not proportional to the granularity of the time slots.With previous work, if the two events above could occur within 20 minutes of each other, a client would require 72 pseudonyms; if the events could occur within 5 minutes of each other, previous works could require 288 pseudonyms.Also, with RRPs the cost of revocation is logarithmic with granularity: only 12 credentials would need to be revoked with a 20 minute granularity and only 16 credentials would need to be revoked with a 5 minute granularity.
Our prototype uses SGX-enabled Intel NUC (Next Unit of Computing) nodes that can be configured to serve as verifiers or a PM server.We measured the latency experienced by clients.Our results show that EDGAR can authenticate clients with low latency, in the order of 0.5 − 3.5 ms, which satisfies the requirements of most latency-sensitive applications, such as augmented reality [68,92,94] and safety applications [4,51,58].We also compared EDGAR with a related work [49] using a real data set of vehicle traces.We show that EDGAR achieves multiple orders of magnitude in storage savings and that the revocation can be performed efficiently, even when using time slots as small as 1 second.

RELATED WORK
Backward Unlinkability has been defined in previous work [49,56,60,76] as follows: when a revocation occurs, the signatures produced by the client before the revocation interval remain anonymous.The notion of unlinkability captures the inability of an adversarial server to link a revocation phase of the protocol to any individual signing phase.We are interested in non-blocking approaches such as VLR [13,16], where the credential of non-revoked clients remain valid, and only the verifiers need to be informed about the credentials of revoked clients.As discussed next, the most popular anonymous authentication schemes that offer BU are based on GS or pseudonyms.In both cases, solutions typically consist of assigning different credentials to different time intervals and then revoking only the credentials for future intervals.Unfortunately, in these previous works, the cost of revocation grows linearly with the granularity of the intervals.Note that if intervals are large, it may be unacceptable to wait for the next interval to revoke the credentials: in this case, it may also be necessary to revoke the credentials for the current interval.Unfortunately, this makes all the credentials used in the current interval vulnerable to being linked.
Anonymous Blacklisting is a term used to describe techniques that are able to safeguard the privacy of revoked clients.Techniques to ensure this goal include the use of pseudonyms [100], group signatures [95], accumulators [7], and zero-knowledge proofs (ZKPs) [99].Most systems that aim to offer anonymous blacklisting also aim at offering BU [50], but either use computationally expensive cryptographic operations or also incur a cost that is linear with the granularity of the linkability window.For example, BLAC [99] relies on inherently computationally expensive ZKPs [50].We avoid the use of ZKPs to implement RRPs due to their high cost; instead, we explore more efficient approaches.
Accumulators, Symmetric Keys, and IBE: Cryptographic accumulators [19] may be vulnerable to linkability [95], i.e., the previously performed operations become linkable when a user is revoked.These solutions also lack VLR since clients need to update their witness at each revocation [7,18].Credentials based on symmetric keys [10] require a high level of trust in the verifier and are susceptible to identity theft if the verifier is compromised [52].Nymble [100] achieves BU but requires a central manager to share a symmetric key with every verifier.Credentials based on Identity Based Encryption (IBE) [12] do not provide anonymity (as they consider the user's identity as the public key) and incur considerable overhead due to expensive cryptographic operations.
Group Signatures with Time-Bound Keys: GS [22] allow different signatures produced by different group members to be verified using a common group public key, achieving anonymity in the set formed by the group members.GS schemes have been augmented with mechanisms to support VLR, as suggested by Brickell [15] and formalized by Boneh and Shacham [13].Unfortunately, in this scheme, the revocation is performed by publishing a cryptographic token that links all the signatures produced from a revoked member, compromising the anonymity of signatures produced before the revocation.Nakanishi and Funabiki [76] extend [13] to offer BU while preserving VLR.Their approach divides the time into slots and locks a different secret key for each slot, revoking only the keys for current and future slots.Chu et al. [24] introduce the notion of Time-Bound Keys (TBK) by setting a configurable expiration date in each key, improving the revocation performance in VLR-GS schemes.In recent years, different solutions have been proposed, following a similar path while aiming to reduce the revocation cost and complexity.LBR [95] requires a trusted online manager to check revocation.Rahaman et al. [89] embed pseudoIDs in private key parameters and ties the pseudoID to an epoch, improving the revocation check complexity to log(), where  is the size of the revocation list.Emura et al. [39] propose an efficient solution with a constant signing cost, but clients are required to download expiration information at each time slot.In Sucasas et al. [96], the authors also achieve BU, yet, their solution prevents clients from participating in the same task several times.Ishida et al. [56] leverage a mixture of IBE with GS, generating IBE private keys locked to time slots.However, their revocation is still based on the GS private key, also having O (  ) (where  is the number of time slots).Despite the interesting properties of GS schemes, GS solutions are usually complex and some may require heavy cryptography operations (such as ZKPs), resulting in few implementations and deployments in real-world scenarios.
Pseudonyms with Bounded Time Slots: Client anonymity can also be achieved by using pseudonyms.These can be implemented using a Public Key Infrastructure (PKI), where clients maintain multiple keys to represent pseudonyms [10,91,93].Pseudonym-based solutions also struggle to offer BU.Some solutions invalidate global information, forcing clients to renew credentials at each revocation [19,47], failing to preserve VLR.V-token [93], IFAL [104] and PRESERVE [41] follow the C2C-CC standard [41], revoking only the long-term vehicles certificates and letting the pseudonyms expire, also failing the VLR.PrivacyPass [35] is an anonymous authentication scheme implemented in Cloudflare CDNs, unfortunately, no revocation technique is presented.PUCA [44] requires the owner of the pseudonym to trigger revocation, letting a misbehaving entity evade revocation.The most common solution is to publish all pseudonyms of the revoked client in a CRL [49,60,97,107], respecting VRL but failing BU.The challenge of maintaining the unlinkability of pseudonyms after revocation was first addressed by Haas et al. [49], followed by Khodaei et al. [60], and implemented in SCMS POC [107] and CAMP [20] pilots, supported by Volkswagen, Mazda, and Nissan.These solutions associate pseudonyms with time intervals and revoke only pseudonyms of the current and future intervals.However, all interactions in the current slot can still be linked and an adversary can use the revocation information to break anonymity [49].
Privacy at the Edge: Edge infrastructures [51], supported by numerous fog nodes [14,25,103], enable computation near clients.Local authentication within edge resources is vital to meet latency requirements and ensure availability.Privacy is a major concern in VANETs, where vehicles generate and transmit substantial amounts of data.Private companies [73,102,105] are exploring ways to monetize user data, often at the expense of privacy, with estimates projecting a worldwide market value of $750 billion by 2030 [73,102].For example, unethical edge providers [6,98] may

H
a a s e t a l. [ K h o d a e i e t a l.
R ig a z z i e t a l. [ Is h id a e t a l. [ N a k a n is h i e t a l.
a n e t a l. [ S u c a s a s e t a l. [ E m u r a e t a l. [ O h a r a e t a l.
C h u e t a l. [ B r in g e r e t a l.sell user data to insurance companies, that can subsequently tailor insurance plans based on individual driving habits [78].Carsharing and rental agencies can exploit user data with the same purpose [45].An attacker could also gain access to user data in the edge infrastructure [9,32,33,38,53,87], inferring if the certain individual is out of the household or has been attending the hospital [69,73,77,79,83,101,102].
To mitigate these problem, pseudonyms are recommended in the GDPR [34] and by ETSI [42], and are a standard practice in various connected vehicle pilot programs of major car manufacturers (ETSI [40], IEEE [74], NHTSA [78]) such as CAMP [30], New York City [55], and Canada [3] pilots.According to a study by ETSI on the use of pseudonyms [41], frequent pseudonym changes enhance privacy: "the more often an ITS-S1 changes its pseudonym, the higher its privacy".However, revoking access rights for a client using different pseudonyms can compromise anonymity when an adversary leverages the revocation information to link the pseudonyms [49].Approaches that mitigate backward linkability by associating pseudonyms with time slots result in increased storage requirements for pseudonyms at the client side and, consequently, in the CRL [49].
Comparison: Table 1 summarizes the differences between the related work.We highlight that, with our RRPs implementation, the size of the revocation information grows only logarithmically with the number of time slots.Cryptographic accumulators do not offer VLR.Symmetric encryption cannot protect user privacy from the verifier, and IBE schemes revoke clients by timeout [12] (failing VLR) or issuing the user identifier in a CRL [37] (breaking anonymity).When using GS, clients can generate multiple unlikable signatures with the same secret key, achieving O (1) for the client storage.Some of these GS schemes revoke clients without providing BU, by simply publishing a token for all possible signatures [16,24].Other solutions cannot provide the VLR property [82,95].Although GS schemes that offer both BU and VLR simultaneously require the revocation procedure to manage a number of credentials that is proportional to the number of time slots O (   ) [89,96] and O (  ) [39,56,76].Another limitation of GS schemes is that they rely on complex and heavy cryptographic operations, in particular, to support revocation; this can induce large latencies when performing authentication.PKI based schemes are appealing due to their cryptographic efficiency and wide adoption.Some PKI schemes delay the revocation until all pseudonyms expire [35,41,93,104], breaking VLR.Previous schemes that provide both VLR and BU suffer from the same issue as GS scheme [49,60,97,107], by locking pseudonyms to time slots, they require revocation information that is linear with the time slots, times each pseudonym, O (   ).In addition, these solutions require the clients to carry pseudonyms for all time slots, imposing a storage burden of O (  ).

SYSTEM MODEL
This section presents preliminaries on RRPs and EDGAR, which is an edge authentication system based on RRPs.In EDGAR, to perform authentication, a client first uses an RRP to obtain a capability.This capability, which is only valid for a given target time slot, is then presented to a verifier.To revoke the use of a RRP during a range of time slots, the corresponding capabilities are revoked.There is a level of indirection between the RRPs assigned to clients and the capabilities used for authentication and revocation that is the enabler to achieve backward unlinkability.

Entities
EDGAR is composed of three main types of entities: clients, verifiers, and a (distributed) pseudonym manager service.We follow a nomenclature similar to previous work [49,89].
Clients: the application client that generates signatures to perform authentication against any verifier.Clients are the holders of RRPs that they use to generate capabilities to ensure anonymity.Clients are responsible for renewing their RRPs when needed.
Verifiers: the component that performs client authentication before granting access to a resource.Verifiers are responsible for checking the capabilities provided by clients before granting access.They are also responsible for updating their state by fetching the list of revoked capabilities from the manager servers.
Pseudonym Manager (PM): this component is responsible for providing new RRPs to clients and, when necessary, revoking capabilities generated from these pseudonyms.PM servers are the only entity capable of accessing the true identity of a client so, in our implementation, they run partially inside a TEE, ensuring users' anonymity even if the device is compromised.
Administrator: a trusted entity responsible for adding clients to the system and request PMs to revoke clients.Figure 1 shows the interactions between these entities, where the PM uses a TEE.The figure represents a typical collective perception scenario, where mobile devices are used to extend human perception.In this example, mobile devices (the clients) authenticate towards the verifiers, to update or download information.When required, clients can contact a nearby PM to renew the set of RRPs used to generate capabilities.Periodically, verifiers will pull from the PM updated revocation information.

Fault Model
We assume a partial synchrony model [36].In this model there are unstable periods when messages may be arbitrarily delayed, and stable periods when messages between correct entities arrive within at most Δ units of time.Additionally, we assume that correct processes have access to loosely synchronized clocks, which can differ at most by .We assume that at most  server nodes can be faulty.We do not place constraints on the number of faulty clients.
Furthermore, verifiers and clients are insecure and prone to Byzantine faults [61].PM servers are executed (partially) inside TEEs and are only subject to crash and omission faults [31].Thus, faulty clients may use expired or invalid credentials when contacting servers, faulty verifiers may arbitrarily deny or grant access to resources, but faulty PMs will never provide faulty information, and will never renew pseudonyms for revoked clients.EDGAR ensures liveness during stable periods and offers graceful degradation during unstable periods: when the network is unstable and nodes are unable to receive up-to-date information in a timely manner, they may stop providing service, but never compromise safety.

Threat Model
We trust only administrators and PMs.Following related work [49,93], an administrator is responsible for adding and revoking users in the system by contacting the PM server.We assume that each PM has a processor with TEE (e.g., Intel SGX), as shown in Figure 1.All other entities within the system are considered untrusted and susceptible to the control of attackers, potentially engaging in malicious activities.Table 2 provides the notations.
Malicious Client: may attempt to generate pseudonyms or capabilities to impersonate a valid client and access resources to which it is not authorized.It can also try to use old capabilities and pseudonyms after being revoked to authenticate towards verifiers.
Malicious Verifier: if a verifier is compromised, the resource that the verifier is protecting becomes unprotected, but this is not the problem we consider in this paper.For example, under a DoS attack, a verifier may be unable to refresh revocation information and should enter a "safe-mode" (the safe-mode behaviour is application specific but may be as simple as halting).The problem we consider is that a malicious verifier may try to perform linking attacks [49,93], by associating (linking) different pseudonyms with a single client, breaking user anonymity.This attack becomes trivial when revocation lists that contain all pseudonyms of a client are published [49].A malicious verifier may collect all the information/data that it observes, e.g., with the objective of deducing user identity.
Malicious Pseudonym Manager: PM code is split in two parts, one that runs inside the TEE and one that runs outside the TEE.The latter can be compromised and engage in malicious behavior, supporting many of the previously introduced attacks.The untrusted part of PM may attempt to modify, delay, block, or read all messages on the system.This behavior may be done in collusion with other entities to facilitate Linking Attacks or allow a user to evade revocation.Furthermore, we assume that a node suffering from denial of service (DoS) is one of the  faulty nodes and that at most  servers can be faulty.
Trust Assumptions: Entities use asymmetric key pairs to establish secure channels.Clients employ RRPs for authentication, integrity, and non-repudiation.Both the PM and the administrator hold unique key pairs, ( −  ,  +  ) and ( −  ,  +  ), respectively, being both public keys known to all entities.Specifically, the administrator's public key  +  is hard-coded in the enclave's source code.We assume that the PM correctly executes our protocol within the TEE, where  −  remains securely within the enclave.The PM will only revoke users if instructed by the trusted and authenticated administrator, and will generate fresh pseudonyms for non-revoked and authenticated clients.We assume that there is no collusion between the trusted PM and the verifiers.
The communication between the administrator and the enclave is based on a PKI using their keys.We assume a trusted administrator who only revokes pseudonyms after informing the corresponding clients.Although supporting revocation auditability is beyond the scope of this paper, we discuss different approaches to extend EDGAR and ensure revocation auditability in Section 5.10.Furthermore, both capabilities and revocation information are accompanied by a digital signature created using  −  , confirming the origin from the PM TEE.
In our work, we make the usual assumptions about the security of TEEs/enclaves [27] (code/data executed/stored inside the TEE have integrity and confidentiality guaranteed), about the cryptographic schemes (they satisfy their security properties) and cryptographic keys (secret and private keys are never disclosed).In the prototype, we use Ed25519 to generate digital signatures [11].As a collisionresistant hash function, we use SHA-256.We use Intel SGX as our TEE, although our scheme can be easily adapted to other TEEs.We leverage the Intel SGX SDK inside the enclave and OpenSSL outside (all in C/C++).
Although side-channel attacks such as Foreshadow and LVI [17] exist, we consider the defense from these attacks to be orthogonal to our contribution; possible mitigations are discussed in Bagheret al. [8].Correctly synchronizing concurrent data structures can mitigate exploits against synchronization bugs [106], with the help of debugging checkers2 [65].

RANGE-REVOCABLE PSEUDONYMS
RRPs are a novel abstraction that provides authentication based on pseudonyms whose validity can be revoked for any time-range within their original validity period.Clients hold a number of RRPs that is proportional to the number of authentication actions they need to perform.A validity of an RRP is bounded to an epoch.An epoch is divided into time slots of length .The parameter  is application-specific but can be small, e.g., 1 minute or less.An epoch is assumed to be much larger than the slot, e.g., 1 day.Each RRP should be used for authentication at most once.To perform authentication, a client instantiates a capability that is specific to target slot.If a client is revoked for a time period, pseudonyms are not revoked directly; instead, only the capabilities associated with the time-slots of that period are revoked.We store these capabilities in an Encoded Revoked Capability Sets (ERCSet).An RRP can be revoked for a short period, by revoking only the capabilities associated with an interval of time-slots, or permanently, by revoking the capabilities associated with all future time-slots.Since the revocation information is connected, indirectly, by capabilities, to pseudonyms, when using RRP, a client is required to carry a different RRP for each access it needs to perform.However, any given RRP can be used at any slot of the epoch.Thus, the number of RRPs a client needs to keep is independent of the granularity of the time-slots.This contrasts with previous pseudonym-based solutions, where clients need to carry a number of pseudonyms that grows linearly with the epoch granularity (i.e., the number of slots in an epoch).

Overview
Authentication based on RRPs uses 3 different related objects, namely (range-revocable) pseudonyms, (time-bound) capabilities, and ERC-Set.At an abstract level, the operations supported by these objects are the following (Appendix C offers the operations workflow): - ℎ ←createRRP(cid, epoch,  −  ): used to create a new RRPs, that can be used by client cid during a target epoch.Only PMs, using their private key  −  , can create RRPs.
-  ←getCapability( ℎ , ,  −  ): used to create a capability associated with an RRP  ℎ for time slot  ( must belong to the epoch for which the pseudonym was created).Only PMs and the client that owns the pseudonym, and the correspondent private key  −  , can create capabilities.
boolean ←verifyCapability(  ,  +  ): To verify if a capability was generated from a valid RRPs, used by verifiers during authentication, requires the PM public key  +  .-ERCSet ←createERCSet(capabilities): used only by PMs to create an ERCSet that encodes one or more given capabilities, using some one-way function, such that it is unfeasible to extract a capability from the ERCSet.These capabilities are filtered to ensure that they do not compromise unlinkability (Section 4.3).
-ERCSet ←mergeERCSet(erc 1 , erc 2 ): used to merge two ERCSets so that a single ERCSet can be used to capture the revocation of multiple capabilities.PMs and verifiers can merge ERCSets.
boolean ←isRevoked(erc, capability): used to verify if a capability is part of an ERCSet.This operation is used by verifiers to check if a capability has been revoked.
The manager creates RRPs on request from authorized clients.If later an RRP needs to be revoked for a given range of time slots, the PM generates the corresponding capabilities and encodes them in an ERCSet that is sent to the verifiers.
Clients hold a small number of RRPs (e.g., corresponding to the number of distinct events), and instantiated a short-lived capability (for the current slot) to authenticate.Then, it presents the capability to the verifier.The verifier checks if the capability is correctly constructed, is genuine (i.e., if it was generated from a valid RRPs) and subsequently check if the capability has not been revoked; only in this case, the client is granted access to the resource.
To ensure unlinkability, a client must never present two capabilities generated from the same RRP, as capabilities generated from the same RRP can be linked (cf.Section 4.3).Therefore, clients have to carry a number of RRPs proportional to the number of resources they need to access.However, contrary to previous systems, the revocation of an RRP for a time-slot does not expose capabilities that may have been used in non-revoked time slots: this is guaranteed by the use of a one-way function to encode revoked capabilities.

Making Range-Revocation Efficient
A problem with the use of time-bound pseudonyms is that the number of pseudonyms that need to be revoked grows with the granularity of the time slots.RRPs are not immune to this problem, because to revoke the use of an RRP in a range of time slots, all capabilities associated with those time slots need to be encoded in the ERCSet.However, our implementation of RRPs uses a mechanism that allows the revocation cost to grow only logarithmically with the granularity, rather than linearly, as previous approaches.
To achieve this goal, a capability is represented by a sequence of latchkeys, extracted from a set of latchkeys that are associated with a given RPP.The latchkeys are organized in a tree of fanout , such that there is a leaf latchkey for each individual time slot on an epoch (in this paper, we use  = 2, i.e., binary latchkey trees).Figure 2 provides a simple example where a binary tree of latchkeys is associated with an epoch of 1 hour divided in 4 time-slots of 15 minutes.Note that the latchkey tree structure resembles but is not a Merkle tree [71]: the tree nodes are generated independently (the value of a parent node does not depend on the value of its children).
A capability for a given time slot is represented by the set of latchkeys in the path from the root of the tree to the corresponding leaf node in the tree.Using the example of Figure 2, the capability for the first slot would be represented by the following set of latchkeys: {, 0, 00}.Note that each capability, for each time slot, is always different, because it contains one unique leaf latchkey.However, different capabilities may have some latchkeys in common; in particular, all capabilities include the root latchkey.
A capability is only considered valid if all latchkeys used to represent it are valid.Therefore, the capabilities can be revoked by invalidating any of its latchkeys.In particular, a capability for a given time slot can be revoked by invalidating the leaf latchkey associated with that slot.However, it is also possible to revoke multiple latchkeys by invalidating latchkeys that are inner nodes of the tree: by invalidating an inner node, all the capabilities that are part of the sub-tree rooted at that inner node are invalidated.This can also be illustrated using our example.Consider that the client is revoked at the beginning of the second slot (01) until the end of the epoch.At this point, the client may already have used its pseudonym  to generate a capability to access the resource during the first slot.To prevent linkability, the latchkeys used in the first slot cannot be revoked, i.e, the latchkeys , 0 and 00 cannot be revealed.To revoke all future capabilities that may be generated with pseudonym , it suffices to revoke latchkeys 01 and 1.Note that the capabilities generated for the second slot must use 01, and the capabilities generated for the third/fourth slots must use 1.
We use this construction to perform revocation efficiently.ERC-Sets do not explicitly contain capabilities, but only latchkeys that belong to those capabilities and a single latchkey can be used to revoke multiple capabilities.It is easy to show that the number of latchkeys that need to be revoked is at most log  with the number of slots.In fact, for each pseudonym valid in the epoch, the number of latchkeys will be given by log  (granularity).

RRP Implementation
We now describe the construction of RRPs.

Scheme assumptions:
We assume that the epoch and time slot size are publicly known to all parties in the system.This means that any party can independently and consistently calculate all the labels from any leaf to the root (i.e., e,  0 , etc.), as illustrated in Figure 2.There is also a maximum number of pseudonyms  that any client can use in any given epoch.

Cryptographic primitives:
We assume there are sources of entropy and a function that allow generating random asymmetric key pairs ( − ,  + ).We assume that there is a function, named DetKeyGen(seed), to generate asymmetric key pairs deterministically from a seed value.There is also a deterministic signature scheme that, given some private key  − and a text as input, will output a deterministic signature sig = DetSign( − , text).The output sig can be verified by true/false = VerSign( + , text, sig).Lastly, there is a secure one-way function Digest(text) that computes a digest on the text input and is not possible to invert given the output.
PM Keys: There is an asymmetric key pair ( −  ,  ).Note that some fields of an RRP are secrets known only to the client and PM and never revealed to a verifier.In particular, only the client and the PM know the secret key  −  associated with a given pseudonym.To obtain an RRP, a client establishes a secure channel with a PM, presents its client identifier cid, and obtains one or more RRPs for some given target epoch.When describing EDGAR, we will discuss for which epochs clients are allowed to obtain RRPs from a PM.

Generating (𝐾 −
,  +  ): The asymmetric key pair associated with a pseudonym is generated using the DetKeyGen() primitive.We use as seed the tuple ⟨cid, epoch, i⟩, avoiding the need for the PM to memorize the information associated with all the pseudonyms it created, as it can always re-create them (as explained below, the key pair is also needed to perform revocation).Recall that cid is known only by the client and the PM.This identifier is securely stored by the PM inside the enclave.Also, DetKeyGen is non-reversible, thus two different public keys created for different epochs and/or instances for the same client cannot be linked with the secret cid.
Latchkeys: Latchkeys are unique for each pseudonym and are obtained by deterministically signing the label of the corresponding node with the private key  −  of the pseudonym.Therefore, the latchkey  0 associated with the label node  0 of an RRP, is generated as  0 = DetSign( −  ,  0 ), and can be verified by using the public key of the pseudonym by performing VerSign( +  ,  0 ,  0 ).Capabilities: A capability  for a given time slot  is a tuple: , sig  ,   , . . .,  00 ,  0 ,   ⟩ where  +  is the public key of the pseudonym and the latchkeys correspond to the nodes on the path from the root of the latchkey tree to the leaf latchkey node associated with the time-slot .Note that a capability has a number of latchkeys that is logarithmic with the granularity of the time-slots in the epoch.The latchkeys that are part of a capability can be generated on demand, when the capability is created, and are not required to be stored explicitly by the client.It should also be noted that any two capabilities generated from the same RRP reveal the same  +  and can be linked; therefore, a client that wants to prevent authorization request to be linked should always use different RRPs.
To verify a capability, a verifier performs the following steps.First, it uses the public key of the PM to verify   , calculating VerSign( +  , epoch ∥  +  , sig  ).Then, it uses  +  to verify if the latchkeys presented with the capability are in fact associated with that RRP, by performing VerSign( +  ,   ,   ).If all latchkeys can be verified using  +  and follow a correct path from the current slot to the root, the capability is genuine.Note that a capability can be genuine but may have been revoked, as explained next.
ERCSet: an ERCset in an encoding of a set of latchkeys that represents a set of revoked capabilities.The set of latchkeys encoded in an ERCset has the following properties: inclusion-of-revoked -if a capability has been revoked, at least one of its latchkeys is encoded in the ERCSet; exclusion-of-non-revoked -if a capability has not been revoked, none of its latchkeys are encoded in the ERSet.Below we explain how latchkeys are selected to be encoded in the ERSet to satisfy these properties.Latchkeys are encoded in the ERCSet using a one-way function, Digest(  ) .Thus, verifiers can check if a given latchkey belongs to an ERCSet but cannot extract latchkeys from the ERCSet.Different data structures that rely on one-way functions could be used to implement ERCSet, including SHA256, or compact data structures such as Cuckoo filters [43], Cascade filters [62] or Count-min sketch [26].We use Bloom filters to implement the ERCSet.Bloom filters are efficient and, as discussed later, a good fit for the EDGAR architecture.A disadvantage of Bloom filters is that they can present false positives, but we will explain later how EDGAR circumvents this limitation.

Revoking a single capability:
To revoke a capability   of a pseudonym , the PM encodes in the ERCSet the leaf latchkey   associated with   .This trivially satisfies the inclusion-of-revoked and exclusion-of-non-revoked properties: the encoded latchkey belongs to the revoked capability but does not belong to any other capability (each capability is associated with a distinct, unique, leaf latchkey).
Revoking a range of capabilities: Revoking a set of capabilities of a pseudonym could be trivially achieved by encoding the corresponding set of leaf latchkeys, but this would have a linear cost.The latchkey hierarchy is used to reduce this cost as follows.Let  be the fanout of the latchkey tree.Any  latchkeys that have the same parent in the latchkey tree can be replaced by their parent.This also satisfies the inclusion-of-revoked and exclusion-of-non-revoked properties of ERCSets: 1) the parent of any latchkey is part of the capability that includes that latchkey and 2) a parent latchkey is not included in capabilities other than the capabilities that include its children.The susbtitution of all  sibling latchkeys by their parent latchkey can be applied recursively in the tree.Note that the root latchkey can only be included in an ERCSet when a pseudonym is revoked for the entire duration of the epoch, because the root latchkey belongs to all capabilities for that epoch.Appendix A provides a precise description of this algorithm with pseudo-code.
Merging ERCSet: An advantage of using Bloom filters is that ERC-Set can be easily merged by performing bitwise OR operations.This makes it easy to disseminate revocation lists for many different RRPs in a single data structure.
Checking if capability revoked: Verifiers receive ERCSets from PMs, store them, and use them to check if the capabilities presented by clients have not been revoked.After checking if a capability is genuine, verifiers test if any of the latchkeys are included in the most recent ERCSet.If even a single latchkey is in the ERCSet, the capability is considered revoked.

RRPs Linkability Analysis
A key problem with previous approaches for performing pseudonym revocation is that the information used for revocation could be linked with the information used for access control (in particular, this is obvious when the pseudonym identifier is used both for authentication and revocation).This allows an adversary to collect information about the resources that have been accessed by revoked pseudonyms.When a client has several pseudonyms that are revoked together, an attacker can link the past usage of these pseudonyms to break the privacy of the user.RRPs avoid this problem because the information used for revocation cannot be linked with the information used for access control.Thus, if a client used one or more pseudonyms prior to revocation, the use of these pseudonyms cannot be linked based on the revocation data.
Here we present an argument that RRPs offer unlinkability.A more detailed proof is provided in Appendix B. Observation 1. Verifiers cannot generate latchkeys associated with a pseudonym.Basis: Latchkeys are generated using the private key  −  of the pseudonym.The private key is generated using the secret cid that is shared between the PM and the client and never revealed to other entities.Therefore, verifiers cannot generate latchkeys.□ Observation 2. ERCSets do not include latchkeys used outside the revocation interval.
Basis: This property is achieved by construction, that ensures the exclusion-of-non-revoked.As described above, when a PM assembles an ERCSet, it never includes in the ERCSet latchkeys that are part of capabilities for time-slots outside the revocation interval.□ Argument 1. Revocation information cannot be linked with authorization information used outside of the revocation interval.

Basis:
The revoked latchkeys are encoded in an ERCSet using Digest(  ), so verifiers cannot extract latchkeys from an ERCSet.Verifiers can only test if a given latchkey has been revoked.However, by Obs. 1, verifiers cannot generate latchkeys, so they can only test latchkeys that are provided by the client when presenting a capability.By Obs. 2, latchkeys for capabilities associated with non-revoked timeslots are not included in an ERCSet.□ Argument 2. Capabilities generated from different pseudonyms cannot be linked.
Basis: All the information in a capability depends on the asymmetric key pair associated with the pseudonym.Asymmetric key pairs for different pseudonyms are different because they are generated using different seeds (the unique instance number  is part of the seed ⟨cid, epoch, i⟩).Additionally, asymmetric key pairs cannot be linked to the seed used for generation (this derives directly from the standard properties of DetKeyGen).□

EDGAR
We now present the design of an anonymous authentication system for the edge that leverages RRPs to offer backward unlinkability.We have named our system EDGAR: EDGe distributed Access contRol, targeting the VANET scenario [10,47,90].The goal of EDGAR is to reduce the linkability window, improving client privacy at the edge.EDGAR demonstrates how to use our RRPs abstraction and how to address implementation challenges in a distributed setting.

EDGAR in VANETs
In the VANET scenario, vehicles continuously broadcast CAM messages [1] containing various information such as their geolocation, sensor readings, direction, and speed.This information is crucial for various edge applications, including enhanced navigation, traffic congestion estimation, remote vehicle diagnostics, autonomous cars, and others [45].However, as explained in Section 2, edge providers can collect and monetize this data, at the expense of users privacy, highlighting the importance for clients to use anonymous authentication methods such as EDGAR.We now contextualize the RRPs entities to the corresponding entities in EDGAR: Clients: These are vehicles that constantly propagate CAM messages with location and sensor readings, with the purpose of enhancing their safety and that of others.
Verifiers: Mainly compose by Roadside Units (RSUs) [29] that listen to all CAM messages, aggregate them, and broadcast them in the network.These devices can be deployed by various local entities (e.g., municipal authorities) or edge providers to improve traffic flow, pedestrian safety, and provide services to vehicles such as infotainment or software updates.
PM servers: These are fog nodes with the same services as verifiers but with higher computational capacity and storage, and may be physically more distant than verifiers.Any fog node with TEEs can serve as a PM.We assume the same trust level as mentioned in Section 3.3, where the PM does not share its private key or the client pseudonyms.However, the PM is controlled by edge providers, who can access the non-trusted zone outside the TEE.
Administrator: In the context of the edge, the administrator should be a trusted entity independent of all applications and providers within the edge.It should work similarly to the current Certificate Authorities (CAs) in PKI.
Figure 3 illustrates the interactions in the edge environment.In this example, a vehicle (a client) presents a capability to the RSU (the verifier).If the capability is valid, the RSU accepts the message from the client and alerts the vehicles about pedestrians behind the corner.Authentication is critical to avoid false information that may cause other drivers to break without justification.The RSU relies on multiple nearby fog nodes, running edge replicas of the PM, to update its state.Vehicles can contact a nearby PM replica to renew the pseudonyms used to generate capabilities, if necessary.
EDGAR prevents the de-anonymization of clients based on the tracking the RRP usage (i.e., even if edge providers like Verizon, Akamai, and Amazon aggregate data from verifiers and the untrusted zone of the PM).Our pseudonyms also protect users' privacy in case of data leaks from verifiers.

Revocation in EDGAR
Although RRPs supports the revocation of a pseudonym in any range of time slots, in EDGAR we assume that clients can be revoked at a target revocation time slot (RTS), selected by the administrator, and that all capabilities of that client are revoked for all time slots after RTS (i.e., the revocation range spans from RTS to the end of the epoch).Also, after being revoked, clients become unable to obtain new pseudonyms from edge PMs after some time.In particular, as we will show later, EDGAR is able to provide the following guarantee: if a client is revoked in a given epoch , that client may still attempt to use pseudonyms it has obtained for epoch  + 1 but will not be able to obtain pseudonyms for epoch  + 2.

Epochs, RRPs, and ERCSet
Time is divided in epochs and epochs are divided in time slots.The length of an epoch and the granularity  of the time slot are application specific.As we show in the evaluation, the efficient revocation mechanism of RRPs, based on the latchkey hierarchy, supports the use of relatively large epochs and fine-grain granularity, for instance, epochs of one day and time slots of 1 minute.
There is a limit I of the number of pseudonyms that a client can request for a given epoch.When using RRPs this is not a limitation because clients only need to have a pseudonym for each access regardless of the time slot where the pseudonym is used (and not a different pseudonym for each time slot, as in previous work).Also, clients are only allowed to obtain pseudonyms for the current epoch and for the next epoch (we allow clients to obtain in advance pseudonyms for the next epoch to avoid having PMs to be overload with a rush of requests whenever an epoch begins).This allows us to limit the number of pseudonyms that need to be added to ERCSet when a client is revoked.Also, verifiers only accept requests that use pseudonyms from the current epoch.This allows to garbage collect revocation information from previous epochs safely.
Due to the constraints described above, EDGAR is only required to maintain two ERCSets: one associated with the current epoch and another associated with the next epoch.When an epoch  terminates, the ERCSet associated with epoch  can be discarded and a fresh ERCSet is created for the next future epoch ( + 2).

ERCSet dissemination
The revocation of a client is initiated in the central PM.The PM first generates all possible pseudonyms that the client may have obtained for the current epoch (i.e., by creating the pseudonyms for all instances 1 . . .I) and creates an ERCSet that revokes all the capabilities that may be generated for these pseudonyms in the range starting from the revocation time slot (RTS) to the end of the epoch.For this, it uses the algorithm described in Section 4.2.It then merges this ERCSet into the global ERCSet  for the current epoch.The PM then generates all possible pseudonyms that the client may have obtained for the next epoch and creates an ERCSet that revokes these pseudonyms for the entire epoch (this is very efficient, because it suffices to include the root latchkey of each pseudonym in ERCSet); it then merges this ERCSet in the global ERCSet  +1 .
Disseminating client revocation among the PMs.The updated values of ERCSet  and ERCSet  +1 are then disseminated in the system using a two-step procedure.First, they are disseminated from the central PM to all edge replicas of the PM.Then, verifiers pull these values from their nearest PM replicas.EDGAR implements the propagation of ERCSets among PM replicas using a gossip-based broadcast protocol.The central PM first selects  + 1 edge PMs at random and sends them the updated ERCSets.When receiving an ERCSet from another replica, a PM checks if the ERCSet is different from the local version.If the ERCSet is the same, it discards the redundant update.If the ERCSet is different, it assumes that it may contain new information and merges it with its own ERCSet, picks other  + 1 edge PMs at random, and sends them the updated ERCSets.This eager push strategy allows revocation information to be propagated quickly on the network.Additionally, a PM that does not receive any updates for more than a predefined gossip timeout engages in pull-gossip with another random PM.Pull gossip is used to recover from temporary crashes or disconnections.A PM that is down when a revocation is eagerly propagated will later obtain the information using pull gossip.Note that the ERCSet for a given epoch always accumulates new information.Thus, any single gossip exchange with an up-to-date server will convey all the information that a node may have missed while disconnected.
Disseminating latchkey revocations to the verifiers.The edge will consist of many verifiers placed at different locations.It is not efficient to have all these PM servers sending the same information to all verifiers.Therefore, we only use pull-gossip to propagate ERCSets to each verifier.Each controller periodically picks a PM at random, pulls ERCSet  from that server, and merges its content with a local copy of ERCSet  .If a verifier fails to execute the pullgossip procedure (possibly due to an adversary jamming the PM), it enters "safe-mode" (the specific behavior varies depending on the application, but could involve stopping the service to protect the resource).

Obtaining New Pseudonyms
Clients can obtain pseudonyms from edge PMs.EDGAR does not require edge PMs to keep an explicit list of all clients that have been revoked and of their corresponding revocation time slot as this is already encoded in the ERCSet.When requesting new pseudonyms, a client establishes a secure channel with any edge PM and provides its own cid and a valid capability.If the client has not been revoked, the PM can provide the requested pseudonyms for the current of for the next epoch.If the client has been revoked, it will be denied access to additional pseudonyms.
To check if a client has not been revoked, a PM performs the following checks: first it verifies if the capability presented by the client is in fact associated to a pseudonym of that client.This procedure leverages that fact that any PM can create all pseudonyms of a client, and therefore, can check if the public key included in the capability corresponds to a public key of one of the valid pseudonyms for that client.Then, it checks if the capability has not been revoked.If the request passes these tests, the PM generates and sends the requested pseudonyms to the client.

Size of ERCSets
EDGAR uses Bloom filters to implement ERCSets.Bloom filters have  (1) insertion and query time [66], are space-efficient, and can be merged easily.However, Bloom filters suffer from false positives and should be used with care.In fact, there is evidence that, if not used properly, the false positives generated by Bloom filters can jeopardize the operation of large-scale systems [62].We first discuss how the size of the Bloom filters used to implement ERCSets is chosen in EDGAR.Later, we discuss how we deal with the fact that false positives cannot be entirely avoided.
The false positive rate of a Bloom filter depends on the filter size  (bits), the number of items to be inserted , and the number  of hash or index functions used for insertion and search.The false positive rate can be approximated as described in [49]: In the case of ERCSets, the average number of items in the Bloom filter is given by: where   is the number of clients,  is the average number of pseudonyms that each client uses,   is the fraction of pseudonyms that may need to be revoked,  is the branching factor of the latchkey tree, epoch is the length of an epoch, and  is the length of the time slot.By using Eq. 2 to compute the number of latchkeys that are expected inserted in an epoch in a Bloom filter, we can use Eq. 1 to select the size of the Bloom filter that limits the probability of having a false positive to some pre-defined threshold.
Let us assume a scenario with   = 250, 000, 000 clients (the estimated number of vehicles in the USA), and assume a fraction of pseudonyms that need to be revoked of 10 −4 per year (from [49]).If we set the length of an epoch 24ℎ, this provides an average of revocations per epoch of   = 10 −4 /365.Then, if we set the granularity of the time slots to  = 10 minutes.This yields 144 time slots per epoch.If we use a binary tree of latch keys, the average number of latchkeys used per revocation is log 2 (144).If we assume that clients need at most 10 pseudonyms per day, the expected resulting number of items to be added to the Bloom filter is:  = 250, 000, 000 × 10 × (10 −4 /365) × log 2 (144) ≈ 4911 In this scenario, a Bloom filter of 9 provides a false positive rate of 0.1% (from Eq. 1).We can determine the false positive rate of a capability by:    () = 1 − (1 − ) ℎ , where  is the false positive rate of the Bloom filter, from Eq. 1, and ℎ is the tree height.In the same scenario, that corresponds to a false positive of 6 in every 1000 capabilities.Additionally, if one wants to increase the granularity of the time slot to  = 1 minute, the number of time slots per epoch increases 10 times, but the number of latchkeys increases only logarithmically, thus the size of the ERCSet must increase only by a factor of log 2 (1, 440)/log 2 (144) = 1.46, i.e, an ERCset of 13 will be enough to maintain the same false positive rate

Circumventing False Positives
Even if the size of Bloom filters is set appropriately, there is always some probability of the occurrence of false positives.In EDGAR we bypass this problem by having clients request  extra pseudonyms, in addition to those that are strictly needed to access the resources.If a false positive occurs, the system automatically picks another unused pseudonym and resubmits the authorization request to the verifier.The only perceived effect by the client is an additional latency in serving the request.We show below that the number of additional pseudonyms that a client needs to carry to circumvent the occurrence of false positives is small.Equation 3 describes the probability that a client will execute all authentication successfully with the help of the  extra pseudonyms.
When applying Equation 3 to the previous scenario, where  = 10 minutes, and setting  = 0, it is possible to derive that 1% of the clients may fail some authentication; this number can be reduced to 1.9 • 10 −12 by setting  = 4.These extra 4 pseudonyms will require increasing the filter size from 9 to just 13 (to achieve the same probability with  = 0 would require increasing the size of the Bloom filter by 34).If each client would require 1000 pseudonyms instead, the probability of a client successfully executing all authentication with  = 0 is just 63% but when using  = 15 it increases to 1 − (1.9 • 10 −14 ), with a storage increase from 883 to 896 (to achieve the same probability with  = 0 would require a filter of 3.89).
Leveraging  extra pseudonymous is a space-efficient solution to make the effect of false positives negligible, even for large-scale systems such as EDGAR.We could consider alternative encoding techniques that completely eliminate false positives, such as cascade filters [62].However, this would require anticipating all possible false positives in order to create the multiple filter levels; in a scenario of millions of vehicles with multiple pseudonyms, this operation would be very expensive and might become infeasible.

Handling Epoch Changes and Quarantine
When a client is revoked, all future capabilities that can be generated from the pseudonyms it may have obtained are revoked.As discussed above, if a client is revoked in epoch , this requires revoking capabilities for future time slots in epoch  and all the capabilities for epoch  + 1. Capabilities for epoch  + 2 and other future epochs do not need to be revoked because EDGAR ensures that a client that is revoked in epoch  cannot obtain pseudonyms for epoch  + 2. This property is guaranteed by a coordination phase that is executed by any PM when it transitions from epoch  to epoch  + 1.The purpose of the coordination phase is to ensure that any PM that enters in epoch  + 1 is aware of all revocations performed in epoch  and, therefore, will refuse to issue pseudonyms for epoch  + 2 to clients that have been revoked in epoch .During coordination, a PM enters in a quarantine mode, where it cannot serve pseudonym requests for epoch  + 2.
The coordination protocol is implemented by forcing each PM to send to every other PM its version of ERCsets  and ERCsets  +1 at the beginning of the quarantine.Furthermore, a PM waits to receive revocation information from at least  −  PMs before ending the quarantine.Because revocation is performed by updating  + 1 PMs, and a PM waits for the input of other  −  PMs, for each revoked client, a PM is guaranteed to receive at least one up-to-date ERCset that includes the corresponding revoked capabilities.At the end of the quarantine, a PM is guaranteed to be fully aware of all revocations that have occurred in epoch  and can start serving requests for pseudonyms in epoch  + 2.

Handling a PM failure
The temporary failure or disconnection of a PM is treated as follows.When the PM server recovers, it will immediately start the pull-gossip procedure.Eventually, it will be able to get up-to-date information on the revoked clients.The same applies to temporarily disconnected PMs.A PM that is offline for a short period of time can operate normally, even if it is slightly outdated.If it is contacted by a verifier, it will not be able to provide the most recent revocation information, but the verifier will be able to fetch that information from another PM in the next gossip interaction.If it is contacted by a revoked client, it may issue new pseudonyms to that client for the current or the next epoch.However, the corresponding latchkeys for those pseudonyms have already been revoked by other PMs, and the client will be revoked in a bounded time.

Revocation Auditability
Informally, revocation auditability refers to a user's ability to verify its revocation status at a service provider before attempting to authenticate.As mentioned in Section 3.3, for the current prototype we assume that the administrator informs the clients before proceeding with the revocation.As future work, we plan to augment the system with additional strategies to support revocation auditability.One approach is to use contract-based revocation [50], where the contract semantics are agreed upon by both the user and the provider.This enables the user to determine whether a certain action will constitute misbehavior before deciding whether to engage in it.Another approach has been implemented in Nymble [100].To ensure that fresh revocation information reaches the client, revocation lists must be published at regular Δ time intervals, containing a signature with the corresponding timestamp.When a client communicates with a verifier, it can first request the list, which must have a fresh signature for the current Δ, and then check if it has not been revoked, otherwise it should halt the authentication process.

Discussion
In this section, we discuss the key features of EDGAR.
Epoch Based Pseudonyms: Pseudonyms in EDGAR are bound to epochs instead of slots.Capabilities are bound to slots, but can be generated at any moment by the client.This decoupling allows clients to store only the desired number of pseudonyms based on application logic, instead of the  granularity of slots.
Space Efficiency: Both edge computing and TEEs have memory constraints, making space efficiency a crucial aspect [27].With EDGAR, revoking a client only requires a logarithmic number of latchkeys, while previous solutions require a linear amount of revocation information relative to the number of time slots (see Figure 4).
Backward Unlinkability: EDGAR revokes future capabilities while ensuring that these capabilities cannot be linked to capabilities used in the past.Unlike previous work, the  granularity of the time slots can be arbitrarily reduced without imposing a burden on the system: the number of pseudonyms used by a client does not depend on  and the cost of revocation is log 2 (1/).Traceability and Accountability: If required, EDGAR can be extended with mechanisms in which verifiers share (limited) information with the PM to provide traceability and accountability.Specifically, a verifier may present one or more used capabilities to the administrator and ask to revoke or trace the anonymous client that is responsible for such capabilities.Depending on the application and the facts to justify the request, the administrator may agree and forward the capabilities to the trusted central PM.

Support for
Since the PM can generate all the public keys associated with the pseudonyms it has provided, it can subsequently match the used capabilities with the clients identifiers (note that only the trusted PM can perform this operation; this does not conflict with ensuring unlikability, which aims at preventing non-trusted entities, such as verifiers, from achieving the same goal).However, we have not implemented or evaluated such extensions as part of this work.

EVALUATION
We evaluate the power of RRPs, using a prototype of EDGAR.We compare the space efficiency of EDGAR against a state-of-the-art scheme for BU in the PKI setting.We also show that our scheme offers a latency suitable for edge applications.Finally, we evaluate EDGAR's throughput when serving pseudonyms.The source code is available at https://github.com/claudio-correia/RRP-EDGAR.
We have implemented both a verifier and a PM server on an Intel NUC10i7FNB.An Intel NUC is an example of what a fog node might be, as it possesses modest computational resources but is relatively inexpensive for large-scale deployments.It has an Intel i7-10710U CPU with Intel SGX, 16GB RAM, and Ubuntu 20.04 LTS.We run the Intel SGX SDK Linux 2.13 Release, Intel SSL-SGX [54] version Linux 2.14_1.1.1kand OpenSSL 1.1.1k.We used a real-world data set composed of multiple vehicle trajectories in the city of Porto [57].

Space Efficiency
We have experimentally compared EDGAR with Haas et al., as both support backward unlinkability by dividing the epoch in time intervals in the PKI setting.Haas et al. scheme was more recently implemented in the SCMS POC pilot [20] under the name of linkage values technique.The comparison is not trivial since the pseudonyms in Haas et al. are locked to a time slot, being invalid if used in any other, while in RRP the pseudonyms are free to be used at any moment of an epoch.
For a clear comparison, we test both mechanisms in a real-world use case of a taxi company operating in the city of Porto, using a dataset of taxi trajectories [57].We choose the mix zones strategy [10,46,86] for pseudonym changes, i.e., taxis change pseudonyms at crossroads.This use case requires a large number of pseudonyms due to constant vehicle movement, favoring the Haas et al. design.In scenarios with fewer pseudonyms needed over the same period, EDGAR will outperform Haas et al. by even larger margins.
Figure 5 shows the results obtained in our experiment.The top part of the figure presents the user latency experienced when acquiring all pseudonyms for a specific epoch, and the bottom part presents the required Bloom filter size for each solution.
In the dataset, we observed that some taxis drive long distances, requiring 692 pseudonyms per day (which entails 5, 677 per moth and 32, 142 per year).Since EDGAR clients can use pseudonyms freely, these values were used as  , the number of pseudonyms instances in an epoch.On the other hand, Haas et al. must fix the number of pseudonyms in each  interval, e.g., with  = 1 min there was a taxi driver who crossed 12 intersections, forcing to fix 12 different pseudonyms for each  interval, which has an explosive effect on the number of pseudonyms generated.Furthermore, as we tighten the  interval, the difference between Haas et al. and EDGAR is more pronounced, for  = 1 sec and epoch = 1 year we observe an improvement of ≈ 2.5 * 10 6 KB to ≈ 6.4 * 10 4 KB, two orders of magnitude lower in the required storage.This results from the logarithmic effect provided by RRPs, while  The use of the latchkey hierarchy makes revocation of a range of time slots efficient, because a single latchkey can be used to revoke many capabilities.The efficiency of revocation comes at the cost of penalty in the authentication procedure, because the verifier must check a number of latchkeys equal to the tree height (instead of verifying only the leaf latchkey).Fortunately, the height of the latchkey tree grows only logarithmically, and latchkeys can be verified in parallel.Therefore, the penalty of RRPs on latency is small.Figure 6 shows the latency of the verification procedure as the granularity of the time slots increases.For instance, a system that uses  = 1 min and an epoch of one day requires a binary latchkey tree of depth 11; if the epoch is increased to a month, the depth of the binary tree increases to 16.In such a case, clients will incur a latency below 2 in a single-thread verifier, still an acceptable latency for edge applications.Note that a tree with 32 levels can support an extreme large number of time slots, such as the ones resulting from using  = 1 sec and epoch = 70 years; even in this case, clients would experience only 3.5 ms of latency.We have used multithreading to parallelize the verification of latchkeys, reducing the impact on latency.We observe a latency reduction that is linear with the number of cores of 47% and 45% from 1 to 2 threads and from 2 to 4 threads, respectively.Hyperthreading, from 6 to 12 threads, offers no improvement since most of the time is spent in cryptographic operations, and each core has a single ALU.

PM Server Throughput
We use the Ed25519 scheme [11] to obtain deterministic digital signatures, but is not yet available in the SGX SDK.Since the PM is responsible for generating the pseudonyms and runs inside the enclave, we implemented two different versions of the Ed25519 inside the enclave: a portable one [85] and one based on OpenSSL [54].
The portable version is straightforward to implement in any type of TEE, but the lack of optimization affects its performance.In the second implementation, we use the Intel SSL-SGX library to import the OpenSSL library into the enclave.This library was designed for the SGX enclaves, being the most efficient implementation of the scheme.We also evaluated the system with and without SGX, using the OpenSSL library outside the enclave as well.Figure 7 presents the pseudonym throughput for each of these implementations.We vary the number of threads on the PM node side, improving throughput as expected.Additionally, we vary the number of pseudonyms that each client requests from the PM, from 4, 8, 16, and 32 new pseudonyms.We observe that increasing the requested pseudonyms also increases throughput by reducing other system overheads, such as signing and encrypting.On the contrary, the number of served clients decreases since the PM server requires more time for each request.Following the previous discussion and fixing  = 1 min, a taxi could request 32 new pseudonyms in just 133 ms, useful for at least the next 32 min.

CONCLUSION
We presented Range-Revocable Pseudonyms, an abstraction that supports an anonymous authentication scheme based on pseudonyms that is able to enforce backward unlinkability with storage costs that are multiple orders of magnitude lower than those of the related work.The gains derive from our novel technique to decouple pseudonyms from time slots, and authentication/revocation procedures based on the use of latchkeys that can be generated from a given pseudonym for any desired time slot.This technique prevents clients from having to store a large number of unnecessary pseudonyms.As a proof of concept, we have designed and implemented a prototype of EDGAR, an authentication system for the edge based on the use of RRPs.We have used this prototype to perform an experimental evaluation using a real dataset of vehicle traces.The results show that EDGAR is capable of offering low latency and storage savings when serving clients.We motivated our work using a VANET scenario, as one of the most prominent use cases for anonymous authentication at the edge computing environment.Still, many other applications, such as crowdsensing, supply chain tracking, augmented reality, etc., also require anonymity and may benefit from our scheme.

A ERCSET CREATION ALGORITHM
We now present in Algorithm 1 the pseudo-code for the algorithm used to implement the createERCSet function, previously described using natural language in Section 4.1.The algorithm receives multiple capabilities to be revoked (from a given pseudonym).It first merges all the latchkeys from the set of provided capabilities (function mergeLatchkeys).Then, the function removeUnsafe will search and remove any latchkeys that may cover time slots that have not been revoked, to ensure that any authentication information that may be used outside the revocation interval, represented by the provided capabilities, is not present in the ERCSet.Afterward, the function removeRedundant will remove any redundant latchkeys, i.e. any latchkey children, that are already covered by their parent.This step is only to achieve efficient storage since it takes advance of our latchkey tree and only requires a logarithmic number of latchkeys to cover the revoked time slots.Finally, the function latchkeysEncoding takes the remaining latchkeys and inserts each one in a Bloom filter that implements the ERCSet.Our prototype implements an optimized version of this algorithm (the code will be released as open source when the paper is accepted).

B UNLINKABILITY PROOF
We now provide a proof that how our implementation of Range Revocable Pseudonyms (RRPs) ensures that the information used to revoke clients cannot be linked to the information used by clients when authenticating on non-revoked time-slots.For clarity of exposition and without loss of generality, the proof considers a single epoch, a single client  with a single pseudonym , and a single Pseudonym Manager (PM).
For convenience we use three sets, MayHaveBeenUsed, Safe and ERCSet, that represent different sets of information that are relevant for the correctness of the algorithm.The set MayHaveBeenUsed contains all latchkeys that the client may have provided when authenticating in non-revoked time-slots.The set Safe contains all latchkeys that are used to perform revocation of a range of timeslots (that corresponds to the output of function removeUnsafe in Algorithm 1).The set ERCSet includes an encoded version of all latchkeys in the set Safe, which results from applying a one-way function to each latchkey in Safe (that corresponds to the output of function latchkeysEncoding in Algorithm 1).Note that the function removeRedundant is relevant to reduce the size of the Safe but is not relevant to the proof (which remains valid, even if this layer of filtering is not applied).
MayHaveBeenUsed captures the information that the client may provide to the verifier when performing authentication.The set ERCSet captures the information included in Safe.We consider that MayHaveBeenUsed and ERCSet are public in the sense that an adversary can be aware of their content.Only the PM has access to the set Safe.
We begin by demonstrating that the sets MayHaveBeenUsed and Safe are disjoint, i.e., that MayHaveBeenUsed ∩ Safe = ∅.Then, we show that encoding the latchkeys of Safe in the set ERCSet achieves the desirable unlinkability.Assumption 1.There is a secure deterministic digital signature scheme.
Definition 7. The Unfiltered Revoked Latchkey Set, or simply Unfiltered, is the union of the latchkeys in all capabilities in the Revoked Capability Set.
The Unfiltered set is obtained by applying the mergeMatchkeys function to the Revoked Capability Set in Algorithm 1. Definition 8.The Safe set is is constructed by applying the re-moveUnsafe function from Algorithm 1 to the Unfiltered set.Definition 9.The ERCSet is constructed by encoding all the latchkeys in the Safe set with one or more one-way hash functions.
In our implementation we use Bloom filters to implement the ERCSet.The one-way hash functions are implemented using Digest(   ) from Assumption 2. Lemma 1. MayHaveBeenUsed and Safe are disjoint.
Proof.We now show that MayHaveBeenUsed ∩ Safe = ∅ by contradiction: The same latchkey being in both sets can be written as: ∃ :  ∈ MayHaveBeenUsed ∩ Safe.
Let us assume that the latchkey  belongs to MayHaveBeenUsed then, from Definition 4, there is a capability   , of a non-revoked time slot , that contains .Let   be the latchkey associated with the leaf node for time slot .Note also that if  is associated with an inner node of the time-slot tree, the leaf node for time slot  is a descendant of that inner node, because a capability includes all nodes in the path from the root to the leaf node, and nodes in the path have a parent-child relation.
Let us assume that the latchkey  belongs to Safe.Then   must belong to Unfiltered, otherwise, because   descends from , function removeUnsafe in Algorithm 1 would remove  from Safe if   ∉ Unfiltered.
Thus, if ∃ :  ∈ MayHaveBeenUsed ∩ Safe then   must belong both to MayHaveBeenUsed and to Unfiltered.Because   is associated with a leaft node, this means that there is a time slot that is both revoked and non-revoked, a contradiction.□ Lemma 2. Only the client and the PM are capable of generating a valid capability   and the respective latchkeys.
Proof.From Definition 3, capability   includes a set of latchkeys.From Definition 2, to construct each latchkey, access to the pseudonym private key  −  is required.From Assumption 1, the key pair ( −  ,  +  ) for the pseudonym  that the client holds is generated using the  as seed in the asymmetric scheme.From Assumption 3 only the client and PM can access the  and, therefore, only the client and the PM can generate  −  .Therefore, only the client and the PM can generate valid latchkeys for the capability   .□ Lemma 3.An adversary can only access latchkeys from MayHave-BeenUsed.
Proof.MayHaveBeenUsed contains all the latchkeys that appear in non-revoked capabilities.An user, to authenticate in a non-revoked time-slot, must generate and present the corresponding capability to a verifier (that is non-trusted).Therefore, the attacker may have access to latchkeys in MayHaveBeenUsed.On the other hand, by Definition 9, ERCSet is constructed by encoding each latchkey   using Digest(  ), and by Assumption 2 the adversary is not capable of inverting any entry in ERCSet to extract a latchkey.
□ Theorem 1.The information used to revoke clients cannot be linked to the information used by clients when authenticating on non-revoked time-slots.
Proof.Revocation is performed using exclusively latchkeys from the Safe set that are encoded using Digest().To link the information provided during authentication with the information used for revocation, the adversary would need to have access to at least a latchkey  ∈ MayHaveBeenUsed and to a latchkey  ∈ Safe.From Lemma 3, the adversary can only access the latchkeys in MayHave-BeenUsed.From Lemma 1, MayHaveBeenUsed and Safe are disjoint.Therefore, the information used to revoke clients (latchkeys from the Safe set) cannot be linked to the information used by clients when authenticating (the latchkeys in MayHaveBeenUsed).□ From Theorem 1, a client using a single pseudonym obtains unlinkability guarantees, since no revocation information can be linked with authorization information used outside the revocation interval.Next we show that RRPs also offer unlinkability when multiple pseudonyms are used.Theorem 2. Capabilities generated from different pseudonyms cannot be linked.
Proof.From Definition 3, all the information in a capability depends on the asymmetric key pair associated with the pseudonym.From Assumption 2, asymmetric key pairs for different pseudonyms are different because they are generated using different seeds (the unique instance number  is part of the seed ⟨cid, epoch, i⟩).Additionally, asymmetric key pairs cannot be linked to the seed used for generation: this is guaranteed by the security of the key generation scheme.□

C RRP PROTOCOL WORKFLOW
We now present in Figure 8 our protocol and workflow in detail for each operation presented in Section 4, and how each entity interacts in the system.

Figure 3 :
Figure 3: EDGAR entities and VANETs interaction at the edge.

Figure 5 :
Figure 5: Storage and latency in Haas et al.Vs EDGAR.

Figure 6 :
Figure 6: Client latency for capability verification, for different levels of granularity and number of threads.

Figure 7 :
Figure 7: Pseudonym throughput and number of served clients by the PM w/ and w/o SGX. is the number of pseudonyms generated in each request.

Table 1 :
Properties and complexity offered by different systems, we omit O () notation for simplicity.

Table 2 :
Table of notations.
+  ) associated with every PM.The private key  −  is only known by the PMs and is kept in the implementation inside the TEE enclave.The public key  +  is known to all participants, including clients and verifiers.RRPs: An RRP is a tuple ⟨cid, epoch, i,  −  ,  +  ,   ⟩ where cid is the client identifier (only known by the client and the PM), epoch is the time windows for which the pseudonym is valid, i is a label that can be used to distinguish each pseudonym instance generated for the same epoch, where  ∈ [1,  ].The ( −  ,  +  ) is a unique asymmetric key pair associated with the pseudonym, and   is the signature performed with the private key of the PM over the concatenation of the epoch, and public key of the pseudonym, sig  = DetSign( −  , epoch ∥  + Distributed Fault-tolerance: EDGAR distributes and replicates the PM functionality.This increases both availability and resilience.It increases availability because clients can obtain pseudonyms from any correct PM.It increases resiliency, because the coordination required to change epoch effectively prevents PMs that have been isolated or whose clock has been attacked from providing new pseudonyms to revoked clients in future epochs (if the clock is moved backward in time and the server generates invalid pseudonyms for old epochs; if the clock is moved forward in time, the server cannot progress through quarantine).
Haas et al. suffers from a linear effect.For large values of , when an epoch is divided into a few time slots, Haas et al. slightly outperforms EDGAR, since the overhead imposed by the latchkey hierarchy is no longer compensated by a significant reduction in pseudonyms.Finally, we also observed that a large number of taxi trips take around 10 min., so we believe that  = 1 min would be a reasonable configuration for this use case, representing a storage saving between 35KB and 15KB (for epoch = 1 day) and 508MB to 51MB (for epoch = 1 year) by implementing EDGAR instead of Haas et al., highlighted with the vertical orange line.