HackerPass Draft

I’m currently working on a project called “HackerPass,” an RFID-based wireless authentication and attendance tracking system aimed at being inexpensive, autonomous, and DIY-able. The motivation for this stemmed from the need for a streamlined attendance and participation reward system for events such as hackathons, and I’m anticipating HackerPass to debut at HackMerced’s Local Learn Day event this autumn as a prototype and later at the main hackathon in the spring as a finished product.

Contents

Preface

To preface, I’m writing this blog post in part so that my colleagues at HackMerced can get up to speed and start working on this project with me. As such, I’m assuming minimum prerequisite knowledge.

In the context of this project, I use the terms “card,” “badge,” and “tag” interchangeably.

Motivation

At events such as hackathons, we want to incentivize people to go to workshops, events, and everything else offered. For example, we may give out event swag for people who have met a minimum threshold of participation – however that may be defined. Attendance tracking with sign-in sheets, Excel spreadsheets, etc. are slow. Stamp cards are lame and easily lost.

RFID cards, on the other hand, can be printed on, slot-punched, and put on a lanyard as a badge. Participants can just scan their own cards at the door. No lines, fuss, or extra personnel needed, and participants get a souvenir to commemorate the event.

10,000’ View

From a high-level view, HackerPass works by having participants scan their badges on badge readers present at sub-events. This scanning process is completely contactless and based on proximity. Cards only need to be close enough to a reader to be properly scanned – there is no swiping mechanism like in magnetic stripe technology.

Scanning the badge will add points to the participant’s account to reward them for going to the event. The number of points associated with an event is configurable to reflect the event’s weight. The participant can check their points balance online with a device such as a smartphone as well as get more information about other upcoming things they might want to check out.

The specific mechanism for allowing users to easily check the account associated with their badge has not been devised yet, but printed, unique QR codes on the badge are currently an idea.

5,000’ View: RFID

RFID (radio frequency identification) cards do not need batteries as they are powered entirely by RFID readers’ radio waves through a phenomena known as inductive or magnetic coupling. In any RFID system, at least one component (tag or reader) must be actively powered. HackerPass is an ARPT (active reader, passive tag) system because the reader is powered by batteries while the tag is powered passively through the reader’s radio waves.

Once the card is powered, it communicates with the reader through radio waves. There are two common types of RFID in use: LF (low frequency) and HF (high frequency). LF typically operates around 125 kHz while HF operates on 13.56 MHz. RFID cards may follow NFC (near-field communication) protocols which operate on the same frequency of 13.56 MHz. HackerPass is HF RFID, NFC.

HackerPass prototype.

When the card and reader communicate, the reader begins by getting the card’s ID. The card responds with its ID. At the moment, this is planned to be the UID instead of the encrypted card data in subsequent sectors. Our threat model makes this trade-off between speed and security possible, and we anticipate using the card’s encrypted sectors to hide Easter eggs.

The reader checks its local cache if the ID is a valid, registered ID. If the cache does not have the ID, the reader will connect to the Internet and ask an online API endpoint if the ID is valid and if so, it will add it to its local cache. If the ID is invalid, the reader will blink red. If the ID is valid, the reader will blink green and communicate with an online API endpoint to increase the number of points in the account associated with the ID by the number of points associated with the sub-event.

Scenario A: a card is in the cache.

Scenario B: a card is not in the cache.

Scenario C: a card is not valid.

The reason why the cache exists instead of simply using the API call’s response to determine authentication (as shown in scenario C) is because adding points to a user’s account is not a time-sensitive need. The points do not need to be added instantaneously, so as long as they’re guaranteed to be added eventually.

If multiple users scan their cards in rapid succession, such as at the start of a sub-event, only one API call is needed to update all of their associated accounts at once. This saves network overhead and energy consumption. In addition, this allows users to have a higher likelihood of being authenticated even if the reader is unable to connect to the API, and the API calls can be made later when a connection is reestablished.

1,000’ View: Provisioning

At the core of the reader is the RFID-RC522 module, which allows read/write operations on HF RFID cards. Thus, the reader can act as not only a reader, but also as a writer. Existing code is available from another one of my projects: mfrc522-mfccli.

A desktop application will allow a device such as a laptop to connect to a HackerPass unit. An unprovisioned card may be scanned and added to a central database of registered IDs online. This should ideally be done after the card’s design has been printed and the card has been slot punched and hung on a lanyard.

Alternatively, a switch can be flipped that can allow the unit to act as a provisioner without the need for a connection to a laptop. Once an organizer has scanned their card, they may scan unprovisioned cards and the device will add the IDs to the online database via API calls to provision them.

Authentication to each sector in a card during provisioning can also allow us to write Easter eggs and other messages in the data.

100’ View: The Finer Details

A HackerPass unit handles wireless communications with an ESP8266 via a NodeMCU. These require a direct wireless connection to a network in order to make API calls. Text-based feedback is provided via a 1602 LCD Display. Although initial prototypes and mockups used separate LEDs for status feedback, this will likely be condensed to a single RGB LED. The RFID-RC522 provides RFID capabilities.

HackerPass 2.0 envisions units connecting to each other through raw RF transmissions, enabling long-distance intercommunication via rateless and distanceless coding, and conserving power through X-MAC. This will remove the need for a direct wireless connection to a network as units can form their own network and act as routers for each other, enabling potentially large-area deployments. Additionally, the ESP8266 platform may be swapped out for something more low-power. Turning HackerPass 2.0 into an autonomous wireless sensor network may see increased power efficiencies and unit lifetime.

HackerPass 1.0 is rather simple so far. There’s nothing particularly special about it – we just have to do it.

The exact specifics of HackerPass are all on the table as of now as development is still very early. More details will be cemented and smoothed out with more testing and prototyping. Until then, that’s all I have to offer.

Happy hacking.