BZPEERReading, trust and collaboration for research
Menu

Discover

GraphFollow connections around a paper, topic or saved view.

Workspaces

HomePick up where your research flow left off.InboxHandle requests, replies and notifications from one place.CollectionsCurate reading lists, evidence sets and shareable dossiers.ResearchSee your private provenance graph, trail and imports.CollaborationMove from discovery into focused discussion rooms.PublishDraft, preview and publish full-text research articles.

Network

ExpertsFind specialists worth following or asking for help.CommunitiesJoin research circles organized around shared work.PartnersSee external organizations active around the same topics.

Opportunities

ListingsBrowse roles, calls and collaborations with clearer fit signals.

Account

Log inReturn to your reading and collaboration workspace.Create accountStart saving work, following people and joining teams.
Log inCreate account

Researcher profile

Joel Reardon

Joel Reardon contributes to research discovery and scholarly infrastructure.

ResearcherAffiliation not importedOpen to collaborate
Cryptography and Securitycs.CY

Trust snapshot

Quick read

Trust 15 - UnverifiedVerification L1Unclaimed author
3works
0followers
2topics
4close collaborators

Actions

Decide how to stay connected

Follow researcher0

Identity and collaboration

How to connect with this researcher

Claiming links this public author record to a researcher profile and unlocks direct collaboration workflows.

Log in to claim

Direct collaboration

Open a focused conversation when the fit is right

Claim this author entity first to unlock direct invitations.

Research graph

See the researcher in context

Open full explorer

Inspect adjacent work, topics, institutions and collaborators without jumping out to a separate graph page.

Building this graph slice

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

3 published item(s)

preprint2020arXiv

Applying Private Information Retrieval to Lightweight Bitcoin Clients

Lightweight Bitcoin clients execute a Simple Payment Verification (SPV) protocol to verify the validity of transactions related to a particular user. Currently, lightweight clients use Bloom filters to significantly reduce the amount of bandwidth required to validate a particular transaction. This is despite the fact that research has shown that Bloom filters are insufficient at preserving the privacy of clients' queries. In this paper we describe our design of an SPV protocol that leverages Private Information Retrieval (PIR) to create fully private and performant queries. We show that our protocol has a low bandwidth and latency cost; properties that make our protocol a viable alternative for lightweight Bitcoin clients and other cryptocurrencies with a similar SPV model. In contract to Bloom filters, our PIR-based approach offers deterministic privacy to the user. Among our results, we show that in the worst case, clients who would like to verify 100 transactions occurring in the past week incurs a bandwidth cost of 33.54 MB with an associated latency of approximately 4.8 minutes, when using our protocol. The same query executed using the Bloom-filter-based SPV protocol incurs a bandwidth cost of 12.85 MB; this is a modest overhead considering the privacy guarantees it provides.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

Proximity Tracing in an Ecosystem of Surveillance Capitalism

Proximity tracing apps have been proposed as an aide in dealing with the COVID-19 crisis. Some of those apps leverage attenuation of Bluetooth beacons from mobile devices to build a record of proximate encounters between a pair of device owners. The underlying protocols are known to suffer from false positive and re-identification attacks. We present evidence that the attacker's difficulty in mounting such attacks has been overestimated. Indeed, an attacker leveraging a moderately successful app or SDK with Bluetooth and location access can eavesdrop and interfere with these proximity tracing systems at no hardware cost and perform these attacks against users who do not have this app or SDK installed. We describe concrete examples of actors who would be in a good position to execute such attacks. We further present a novel attack, which we call a biosurveillance attack, which allows the attacker to monitor the exposure risk of a smartphone user who installs their app or SDK but who does not use any contact tracing system and may falsely believe that they have opted out of the system. Through traffic auditing with an instrumented testbed, we characterize precisely the behaviour of one such SDK that we found in a handful of apps---but installed on more than one hundred million mobile devices. Its behaviour is functionally indistinguishable from a re-identification or biosurveillance attack and capable of executing a false positive attack with minimal effort. We also discuss how easily an attacker could acquire a position conducive to such attacks, by leveraging the lax logic for granting permissions to apps in the Android framework: any app with some geolocation permission could acquire the necessary Bluetooth permission through an upgrade, without any additional user prompt. Finally we discuss motives for conducting such attacks.

0 citations0 reviewsNo code linkedOpen access
preprint2020arXiv

SwissCovid: a critical analysis of risk assessment by Swiss authorities

Ahead of the rollout of the SwissCovid contact tracing app, an official public security test was performed. During this audit, Prof. Serge Vaudenay and Dr. Martin Vuagnoux described a large set of problems with the app, including a new variation of a known false-positive attack, leveraging a cryptographic weakness in the Google and Apple Exposure Notification framework to tamper with the emitted Bluetooth beacons. Separately, the first author described a re-identification attack leveraging rogue apps or SDKs. The response from the Swiss cybersecurity agency and the Swiss public health authority was to claim these various attacks were unlikely as they required physical proximity of the attacker with the target (although it was admitted the attacker could be further than two meters). The physical presence of the attacker in Switzerland was deemed significant as it would imply such attackers would fall under the Swiss Criminal Code. We show through one example that a much larger variety of adversaries must be considered in the scenarios originally described and that these attacks can be done by adversaries without any physical presence in Switzerland. This goes directly against official findings of Swiss public authorities evaluating the risks associated with SwissCovid. To move the discussion further along, we briefly discuss the growth of the attack surface and harms with COVID-19 and SwissCovid prevalence in the population. While the focus of this article is on Switzerland, we emphasize the core technical findings and cybersecurity concerns are of relevance to many contact tracing efforts.

0 citations0 reviewsNo code linkedOpen access