key: cord-0119309-wb540hav
authors: Chen, Bo-Rong; Hu, Yih-Chun
title: BlindSignedID: Mitigating Denial-of-Service Attacks on Digital Contact Tracing
date: 2020-08-21
journal: nan
DOI: nan
sha: 4e84f6a67b0cb8087b5948f5b161bdd66d565c48
doc_id: 119309
cord_uid: wb540hav

Due to the recent outbreak of COVID-19, many governments suspended outdoor activities and imposed social distancing policies to prevent the transmission of SARS-CoV-2. These measures have had severe impact on the economy and peoples' daily lives. An alternative to widespread lockdowns is effective contact tracing during an outbreak's early stage. However, mathematical models suggest that epidemic control for SARS-CoV-2 transmission with manual contact tracing is implausible. To reduce the effort of contact tracing, many digital contact tracing projects (e.g., PEPP-PT, DP-3T, TCN, BlueTrace, Google/Apple Exposure Notification, and East/West Coast PACT) are being developed to supplement manual contact tracing. However, digital contact tracing has drawn scrutiny from privacy advocates, since governments or other parties may attempt to use contact tracing protocols for mass surveillance. As a result, many digital contact tracing projects build privacy-preserving mechanisms to limit the amount of privacy-sensitive information leaked by the protocol. In this paper, we examine how these architectures resist certain classes of attacks, specifically DoS attacks, and present BlindSignedIDs, a privacy-preserving digital contact tracing mechanism, which are verifiable ephemeral identifiers to limit the effectiveness of MAC-compliant DoS attacks. In our evaluations, we showed BlindSignedID can effectively deny bogus EphIDs, mitigating DoS attacks on the local storage beyond 90% of stored EphIDs. Our example DoS attacks showed that using 4 attackers can cause the gigabyte level DoS attacks within normal working hours and days.

In light of the success of several countries' SARS-CoV-2 containment strategies based on aggressive contact tracing, several researchers have developed approaches to digital contact tracing [4, 6, 7, 8, 13, 17, 34] . Because of the privacy concerns inherent with disclosing user location traces, several proposals include mechanisms for privacypreserving proximity tracing. These mecachisms make use of a limited-time identity to reduce an adversary's ability to track that device from broadcast to broadcast; these identities are variously called ephemeral ID [34] , Temporary ID [13] , and Rolling Proximity ID [4] ; in this paper, we will use the term ephemeral ID or EphID. To reduce the amount of bandwidth needed to disseminate positive identities, these ephemeral IDs are generated from a master secret in a one-way manner, such that the master secret is sufficient to derive all relevant ephemeral IDs, but that several ephemeral IDs leak no information about other associated ephemeral IDs.

In existing designs, a user receiving an ephemeral ID can neither associate that ephemeral ID with other ephemeral IDs from the same contact, nor can the user verify the validity of an ephemeral ID that it receives; as a result, a user must store all of the ephemeral IDs that it encounters across the maximum incubation period (widely set at 14 days for SARS-CoV-2). Furthermore, storing these ephemeral IDs in the cloud faces significant privacy challenges; if a large fraction of users trust a single cloud storage provider to store unencrypted ephemeral IDs, that cloud storage provider would learn extensive privacy-compromising information about a user's social structure. As a result, existing schemes [4, 6, 8, 17, 34] largely assume that ephemeral IDs are stored on the user's own device until the incubation period has expired. However, because of the limited storage available on commonly-used mobile devices, an attacker can send a large number of bogus ephemeral IDs, overwhelming the storage of all but high-end devices. We call this attack the DoS attacks. In fact, the existing EphID-based designs [4, 6, 7, 8, 13, 17, 34] are widely adapted by many countries [3, 5, 7, 10, 13] , which occupy approximately 12.5% [37] of the world population, thus making these people's mobile devices vulnerable to DoS attacks. In this paper, we propose a design for BlindSignedIDs, where receivers can verify ephemeral IDs in-place, and senders can generate only a limited number of ephemeral IDs based on a resource constraint, such as personal phone numbers, that must be verified before privacy-preserving verifiable ephemeral identifiers are issued, while still providing privacy from the certificate authority through the use of blind signatures. The rest of this paper is organized as follows: in Section 2, we make system assumptions and describe the attacker model. In Section 3, we describe the security issues regarding current designs of digital contact tracing. Section 4 introduces our approach in detail. We provide an analysis of BlindSignedID in Section 5 and 6. Section 7 demonstrates our example DoS attacks and BlindSignedID can effectively reduce DoS attacks. Section 8 reviews current projects. We make conclusions in Section 9.

Threat Model

Each received EphID is kept in the user's local storage for at least 14 days. The stored EphID includes additional information (e.g., encountering time and duration), which consumes fixed-byte spaces in the local storage. Moreover, the user stores every received EphID regardless of any encountering duration for recording and checking exposure. Finally, the mobile devices support Bluetooth Random Private Address [1] , where each received EphID cannot be linked to the real Bluetooth device address.

The attacker is able to modify the BLE protocol such that her device can advertise BLE beacon packets with the minimum interval. Namely, the transmission interval is not bounded by the underlaying BLE stack (e.g., maximum and minimum intervals in BlueZ [2] ). She specifies the standard BLE flags with arbitrary content (i.e., spoofing EphID) such that other users will receive and keep the packets in the local storage. Morever, the attacker uses a powerful BLE antenna for larger transmission ranges.

In this section, we describe DP-3T [34] at a high level, to set the context for our attacks and our approaches. DP-3T generates ephemeral IDs using:

where EphID i is a 16-byte ephemeral ID, SKt is secret day seed, PRF is a pseudo-random function, and PRG is a pseudo-random generator. To further reduce the amount of information disseminated for a positive report, DP-3T generates the next secret day seed SKt by hashing the previous secret day seed SKt−1 with a one-way hash function, so that the dissemination of one secret day seed allows contact tracing for all subsequent days. Each user generates 288 EphIDs per day, randomly reorders them, and uses Bluetooth Low Energy (BLE) to broadcast each EphID for one epoch (5 minutes). A device receiving such a beacon stores the EphID, signal strength information (such as RSSI), and the date on which the beacon was received, for a total of 36 bytes per EphID for the low-cost design and 52 bytes for the unlinkable design [34] . A receiving device must store these records for 14 days. When a user tests positive, her secret day seeds from the infectious period will be uploaded to the backend, so that other users can fetch seeds and compare with their local records to determine whether they have been in contact with this particular user.

Although storing in local space with user-generated ephemeral IDs reveals no information from the user, it suffers from DoS attacks. Specifically, because a user cannot link messages from different secret-day seeds (and even if they could, the attacker can choose arbitrary secret-day seeds), an attacker with a high-power Bluetooth antenna can stream newly-generated ephemeral IDs limited only by bandwidth. BLE has bandwidth of 1-2 Mbps, so any receiver within transmission range of an attacker will need to store (based on the overhead specified in the DP-3T paper) 1-2 GB per hour or 8-16 GB for an 8-hour day. Even when considering the possibility of compression or elimination of certain data, the incompressible EphID alone will amount to between 450 MB and 900 MB per hour, or 3.6 GB to 7.2 GB across an 8-hour working day. Since many phones do not have several gigabytes of available storage, such an attacker can cause the victims phone to run out of space. We believe that the lack of authentication of ephemeral IDs makes many privacy-preserving contact tracing approaches [4, 6, 7, 8, 13, 17, 34] vulnerable to DoS attacks.

Our approaches are designed for the attacks listed above, and not for other, similar attacks. In this section, we describe similar attacks that we do not attempt to address, and discuss the design choices that led us to draw these boundaries.

Our DoS attacks aims at MAC-and-PHY-compliant attackers. While previous work has examined jamming attacks against the physical layer [22, 23, 27, 33] and other attacks against the MAC layer [11, 14, 15, 18, 19, 25, 28] , the aim of digital contact tracing is to be immediately available on commodity hardware, which includes commodity wireless chipsets. As a result, mechanisms that require new approaches to the physical-layer or MAClayer are non-starters for these protocols. Furthermore, the level of complexity required to build jamming devices or MAC-layer attacks makes these attacks less practical than ones that can be built on any Bluetooth compatible system. When future devices may include support for more robust physical-and MAC-layers, our work can integrate with these approaches for greater robustness.

In this section, we describe our approach to the attacks discussed earlier. First, we examine how ephemeral IDs can be verified. Previous work [12, 26, 29, 30, 36] have developed schemes that use attacker's resource limitations (e.g., ability to compute computational puzzles or solve CAPTCHAs) to create fairness between normal users and automated attackers. Our approach to BlindSignedIDs builds on this work to limit the ability of adversaries to create unbounded numbers of valid ephemeral IDs. In particular, verifying a user's real identity or phone num-ber can serve as the basis for generating a set of valid identifiers in a privacy-preserving way.

BlindSignedIDs. We build verifiable ephemeral identifiers on subliminal-free blind signatures [21] , illustrating the approach using RSA blind signatures. The signer first generates a public-private key pair for each day; we call (et, dt) the verification and signing exponent used on day t − 2 to create credentials for day t. (The modulus n should also change from day to day.) Both the verification exponent, the modulus, and a Prefixt (used to pad the EphID to a length suitable for signing) are published in advance of day t−2. On day t−2, the user creates a main secret day seed skt, and uses a pseudo-random generator on skt to generate M secondary secret day seeds:

(where M is chosen to reduce the chance that an attacker generates EphIDs corresponding to a secret key; we suggest M = 100) and generates M sets of EphIDs using

The user then blinds each EphID. To blind EphIDs in a manner easily verifiable by the signer, the user chooses a main blinding seed bt and uses a pseudo-random generator on bt to generate M secondary blinding seeds bt i , one for each secondary secret day seed:

The user then uses a pseudo-random generator on each bt i to compute a set of blinding values for each EphID,

where et is the signer's public exponent, and blinding the EphID

Prefixt is a value chosen for that day to pad the EphID to the size of the RSA group. For example, if we use 2048-bit RSA and 104-bit EphID, the Prefixt is 1944 bits. In this manner, the user generates M sets of n blinded EphIDs, each of which corresponds to a single secondary secret day seed. The user then contacts the backend server, proves .

where dt is the private key for signing on day t − 2 (and use on day t). If EphIDs are not correctly generated, the signer adds the user into a blocklist, such that the credentials she used are not valid at the signer for a certain period of time (the length of time to be chosen should depend on the possibility of reassignment; for example, longer-term blocking for national identities and social media accounts may be reasonable, but blocks for phone numbers should expire after a few months). By ensuring that EphIDs are generated correctly, we can ensure that a positive test can be represented by a single secondary secret-day seed, ensuring that anyone broadcasting verifiable ephemeral identifiers can correctly report a positive test. Figure 1 illustrates the registration process.

The user computes signatures SDi from the signed val-ues SD i j by inverting theri j used to blind each EphID is :

EphIDs generated and signed on day t − 2 are used on day t. We can choose an arbitrary period for signing and refreshing keys, but we choose a day in line with DP-3T [34] .

Because BLE beacons only have 31 bytes of space, of which 3 bytes are used for BLE flags, including a blind signature for an EphID into the beacon would require the use of several beacons, which could lead to computational attacks on packet defragmentation. To avoid these possibilities, we propose to have the signer exchange signed EphIDs for EphIDs authenticated using TESLA [31] . TESLA uses authenticators based on symmetric cryptography to provide broadcast authentication by using the time at which information is disclosed as the mechanism for creating asymmetry. In particular, the entity wishing to authenticate messages (in this case, the signer) creates a sequence of keys using a one-way hash function: k1, k2 = H(k1), . . . , ki+1 = H(ki) . . ., and a schedule at which these keys will be released: t1, t2 = t1 + T, . . . , ti+1 = ti + T . . ., as illustrated in Figure 2 . The signer will release key ki at time ti, so if a verifier receives a message before the signer's clock has reached ti, the signer knows that the message is authentic if it is authenticated using the key ki. TESLA relies on loose time-synchronization for security, meaning that each clock must be within a bounded margin of error ∆ from the signer's clock (in our design, T will be approximately 5 minutes, and the maximum timesynchronization error will be around 10 seconds). Thus, if the message is received before time ti − ∆ on the receiver's clock, the receiver knows that it is before time ti on the signer's clock.

To exchange RSA blind-signed verifiable ephemeral identifiers for TESLA-authenticated MACs corresponding to each EphID, a user requests them through a MIX [20] on day t − 1, providing a nonce, an encryption key, the EphID, the corresponding signature SD, and the time interval at which the user intends to use them on day t (these time intervals should be standardized across all requesters to minimize privacy loss). The signer verifies the signature, and if valid and not requested before, generates the authenticator (Auth) for the requested time interval. The signer then encrypts the authenticator using the encryption key and publishes the nonce and encrypted authenticator. On day t − 1, a user can retrieve their authenticators for day t using one of three approaches: (i) full download: the user downloads the entire list of nonces and encrypted authenticators, discarding all values other than the ones chosen by the user; (ii) partial download: the user intially constructs the nonces so that they are equal in some bits; the user then requests a subset of the list by specifying the bits that are equal across all of that users' requests; (iii) individual download: a user with limited resources can also request their authenticators through anonymous connection such as Tor [9]. Because authenticators for each EphID are requested separately through a MIX, the signer cannot link two EphIDs except to know that EphIDs authenticated for the same time are likely to be from different users.

When broadcasting a beacon, a user broadcasts the EphID and the TESLA authenticator used for the current time interval. When receiving a beacon, a receiver carries the EphID, the Auth, the time of receipt, and the signal strength. A beacon is kept for two time intervals; if the two keys following the time of receipt do not match the Auth, then the receiver knows that the EphID is not authenticated for the interval in which it was used (see evaluations in Section 7.1). Finally, we use 13 bytes (104 bits) for both EphIDs and Auth to fit within the 28-byte payload limit, as shown in Figure 3 

When a device receives a beacon, the user stores them as (EphID i , Authi, time, RSSI). When the user obtains the current released key ki at time ti from TESLA server, she firstly verifies ki with ki−1 by a one-way hash function; she then verifies each EphIDs received in the previous period by checking its authenticator Authi. If the Authi is valid, the device accepts the record and keeps that record in longer-term storage; authenticator verification can be performed in-place to mitigate DoS attacks. Optionally, our protocol can be combined with [32] to prevent relay and replay attacks. However, the details of preventing relay and replay attacks are beyond the scope of our protocol.

When a health authority determines a user is a positive case, all her secondary secret-day seeds and the selected numbers s during the infectious period (typically 2 days before symptoms happen) are published in a blockchain, together with a sequential case number for the day of publication. Each user fetches the list of these positive cases, and generates EphIDs with the secondary secretday seeds and the selected numbers s, and compares the EphIDs with the EphIDs in their local storage. If there is a match, the device can suspect contact with a positive case.

FinalTrial. We propose to use the blockchain to provide an additional defense to the identifier-spoofing attacks. When a user generates BlindSignedIDs, she also requests blind-signatures for a set of codes of the form i || ni, where ni is a nonce and i represents a sequential case number; these codes are signed with a daily signing key different than the signing key used for BlindSignedIDs. Specifically, the user generates sufficient codes to respond to the maximum number of positive tests that might reasonable affect her jurisdiction for a day. Each such test is a nonce ni. She then builds a Merkle tree over these nonces, by first hashing each one, then hashing adjacent pairs to reach a tree root. She blinds the tree root R by calculating Rr e t i , has it signed as s = (Rr e t i ) d t , and unblinds the signature by calculating SP = r −1 i si = R d t . When a device matches positive case number i, instead of immediately notifying the user, the device posts ni, SP, and the Merkle path required for verification to the blockchain, allowing each user to determine the number of matches corresponding to each positive case. When a single positive case experiences an excessive number of matches, the device may choose to warn the user that the match seems unlikely, or may entirely ignore the match.

In our design, real IDs (such as phone numbers) are revealed to a signing server before the server provides EphIDs. Since EphIDs are blind-signed with a subliminal-channel-free signature, each EphID is indistinguishable, and could be associated with any real ID that was presented on the day on which it was signed.

Lemma 1. Given two signed EphIDs, EphID 1 and EphID 2 , and two possible identities, A and B, the signer can gain no advantage on which EphID is assigned to which identity; that is, any attempt to assign EphID i to A succeeds with probability 1/2. The set R is sent to the signer, and the signer signs each EphID in R using the private key d. Since r ed i = rimod N, the signer generates a signature set SD SD := {EphID d 1 * r1 mod N, ..., EphID d n * rn mod N} (10) The signer learns the signature set SD is associated with the user's real IDs. However, for any pair of values (x, y) in the signature set SD (EphID d x * rx mod N, EphID d y * ry mod N) ← SD (11) Since the blinding factors are randomly generated, they could take on any value. For example, if we consider two EphIDs, EphID 1 and EphID 2 , blinded as follows: (EphID 1 * r e 1 , EphID 2 * r e 2 ), these are indistinguishable from (EphID 2 * (EphID 1 * EphID −1 2 * r e 1 ), (EphID 1 * (EphID 2 * EphID −1 1 * r e 1 )). In other words, for each EphID EphID i and each blinded EphID EphID j r e j , there exists a blinding factor for EphID i such that the signing request for EphID j would create a signature for EphID i . Naturally, the security of the blind-signature scheme requires that such blinding factors be computationally difficult to compute, but they exist and are equiprobable blinding factors: specifically, if a signer generates N signatures on one day, then for any given EphID, there are N blinding possible blinding factors, each of which corresponds to one blind-signature request. Each such blinding factor is indistinguishably probable to the signer.

When a user provides authenticators to the signer, she also includes the time interval and a nonce; the signer therefore learns only the which EphIDs are used in each time interval, and the correlation between nonces and EphIDs. First, if the signer is not compromised, there is no privacy loss, because only the signer has the correlation between EphID and nonce. Even when the signer is compromised, a user adopting the full download method reveals no information about her authenticators. However, the size of download lists might be multiple gigabytes if there are millions of participants. The partial download method saves user resources at the cost of some privacy in case of a compromised signer; however, revealing only a small part of the nonce (e.g., 1 byte of a 16 byte nonce), each user still retains a significant anonymity set. Finally, the individual download method loses more privacy in case of a compromised signer, but the specific amount of privacy loss depends on the mechanism by which the values are downloaded (for example, when downloading over Tor [9] , the privacy properties are the same as Tor's).

Mitigate DoS attacks. BlindSignedIDs mitigate the DoS attacks by ensuring that each EphID stored by a user is an EphID generated for a valid user. BlindSignedID provides an in-place verification to mitigate the DoS attacks on the local storage in that the user will reject an arbitrarily generated EphID that is not associated with a real identity.

Single attacker.

In this section, we evaluated BlindSignedID via sending BLE beacons using mobile devices. Figure 4 shows our experimental setup. We implemented a release key UDP server as the TESLA server, and each key was released every 5 mins. Moreover, we built an Android application to advertise BlindSignedID and scan BLE beacons on two victim's phones placed at a distance of around 20 cm. For the single attacker, we generated a set of 70,000 random EphIDs sent by a single Raspberry Pi 3 Model B with the distance 1.5 m. We used the first 13-byte of HMAC-SHA1 as authenticator. Each random BLE beacon was broadcasted and the rotating time was 20 ms. The receiver stored each EphID with the time of first receipt, duration, RSSI and authenticator temporarily. Whenever a key release is scheduled, the receiver fetches the key over UDP, checks the key, and for each record, attempts to verify the record. When a record is verified, the receiver puts the time of first receipt, duration of contact, and RSSI in local storage, consuming 38 bytes per EphID. Figure 5 shows our results. Our BlindSignedID rejected all DoS attacks periodically created by the attacking set, and prevented nearly 30,000 fake EphIDs stored in 30 mins. Consequently, the original EphID designs are vulnerable to DoS attacks, and BlindSignedID can mitigate such attacks in-place. In an actual attack, the attacker can further modify BlueZ stack to transmit BLE beacons as frequently as possible, so DoS attacks are even more severe under such circumstances. Multiple attackers.

In addition, we evaluated BlindSignedID with multiple attackers to somewhat mitigate the long interval between attacker EphIDs. We gen- erated 4 sets of 4,320,000 random EphIDs, which were used by 2 and 4 Raspberry Pis. Figure 6 shows that 2 and 4 attackers using off-the-shelf BlueZ broadcast intervals can cause approximately 1,227,000 and 1,891,000 stored EphIDs within 8 hrs, representing 645 MBytes and 1.076 GBytes across 14 8-hour days, respectively. Due to networking and processing delays, receivers do not filter all of the invalid EphIDs every 5 minutes, but the system still trends towards significant reductions in storage requirements. Crowded environment. We performed 3 experiments where over 14 people were originized in grid positions with a distance of 0.5 m, 1 m, and 1.5 m in a middlesize room, respectively. (These experiments were conducted in compliance with local social distancing requirements.) We used 6 Raspberry Pis as the attackers to send random EphIDs near the same power outlet. Each scenario was conducted for 1-2 mins. Table 1 reported the numbers of received EphIDs and real EphIDs verified by BlindSignedID. As distance increases, devices receive fewer EphIDs due to signal strength losses over longer distances. Also, our BlindSignedID continues to effectively reduce storage consumption, removing over 90% of the identities produced by DoS attacks.

This section reviews several papers that inspire BlindSignedID. Digital Contact Tracing. BlindSignedID mostly fol- lows the current design of DP-3T [34] , where a secret day seed is used to generate a set of ephemeral identifiers. Most current projects follow the similar designs. However, current designs suffer from DoS attacks. Although BlindSignedID is based on DP-3T, it can be applied to a wide range of projects based on ephemeral IDs, such as [4, 6, 7, 8, 13, 17, 34] . Moreover, the user registration of BlueTrace [13] utilizes the phone number to acquire a unique, randomised user ID from the backend server. Like BlueTrace, BlindSignedID requires the real IDs (e.g., phone numbers), but the BlueTrace server can learn which particular phone number is linked to which user ID. In other words, the signer can violate the user's privacy; in BlindSignedID, by contrast, the signer learns no information that can associate an ephemeral identifier with a real ID, other than the day on which the EphID was signed and the set of real IDs that authenticated on that day. The ROBERT protocol [16] , a framework related to PEPP-PT [7] , suggests that the proof-of-work system can be used during application registration to prevent from automatic registrations, but it does not solve the DoS attacks in-place on local storage, and the wide range of computation power available to different devices makes it difficult to simultaneously allow older mobile phone users to create identities while also preventing wellresourced attackers from creating thousands of identities.

Replay and Relay Attacks. [32, 35] seek to prevent replay and relay attacks on DP-3T. Such attacks can be performed by broadcasting ephemeral IDs generated by published secret seeds. Since these published seeds are positive cases, other users receive false alerts due to such attacks. [35] propose an interactive protocol to prevent such attacks, but it might not be efficient for digital contact tracing. [32] further present Delayed Authentication, which is a non-interactive method to prevent (longterm) replay and relay attacks. They tie a BLE broadcast beacon to time and location information through a key. The receiver verifies potential positives with the backend server. BlueTrace [13] utilizes encrypted User IDs with timestamps as TempID for beaconing, thus mitigating long-term replay attacks (but not relay attacks) by validating the timestamps of each TempID after the user uploads all records. In summary, these proposals prevent long-term replay attacks and potentially relay attacks by including time information and keys in BLE beacons. However, the current digital contact tracing systems still suffer from DoS attacks.

In this paper, we present BlindSignedIDs, which can mitigate DoS attacks on the current digital contact tracing designs. In particular, we propose BlindSignedIDs that are verifiable without compromising the user's privacy to mitigate DoS attacks. Anonymous identifiers do cause the mass surveillance difficult to be conducted. However, using anonymous identifiers without verifications introduces security issues in the current designs. Finally, we evaluated our BlindSignedIDs with example DoS attacks and showd BlindSignedIDs can reduce DoS attacks.

Bluetooth technology protecting your privacy

Bluez: le set advertising parameters cp

Cdc digital contact tracing tools for covid-19

Google/apple privacy-preserving contact tracing

Japan releases contact-tracing app using apple and google tech

Pan-european privacy-preserving proximity tracing

Uk abandons contact-tracing app for apple and google model

A jamming-resistant mac protocol for single-hop wireless networks

Spammers pay others to answer security tests

Bluetrace: A privacy-preserving protocol for communitydriven contact tracing across borders

802.11 denial-ofservice attacks: Real vulnerabilities and practical solutions

Performance comparison of detection schemes for mac layer misbehavior

Robert: Robust and privacy-preserving proximity tracing

Pact: Privacy sensitive protocols and mechanisms for mobile contact tracing

Securemac: Securing wireless medium access control against insider denial-of-service attacks

Simplemac: A simple wireless mac-layer countermeasure to intelligent and insider jammers

Untraceable electronic mail, return addresses, and digital pseudonyms

Blind signatures for untraceable payments

Cross-layer jamming detection and mitigation in wireless broadcast networks

Broadcast anti-jamming systems

Quantifying sars-cov-2 transmission suggests epidemic control with digital contact tracing

Denial of service attacks at the mac layer in wireless ad hoc networks

Proofs of work and bread pudding protocols

Selfish mac layer misbehavior in wireless networks

Torpolice: Towards enforcing service-defined access policies for anonymous communication in the tor network

Portcullis: Protecting connection setup from denial-ofcapability attacks

The tesla broadcast authentication protocol

Delayed authentication: Preventing replay and relay attacks in private contact tracing

Anti-jamming broadcast communication using uncoordinated spread spectrum techniques

Apostolos Pyrgelis, Daniele Antonioli, et al. Decentralized privacy-preserving proximity tracing

Analysis of dp3t. Cryptology ePrint Archive

recaptcha: Human-based character recognition via web security measures

List of countries and dependencies by population