- Hi, I'm gonna be talking to you today
about hacking RFID attendance systems
to be in two places at once.
Our story begins in the spring of 2020 with an unnamed
18-year-old computer science undergrad student.
With just two requirements left, he's about to become
the youngest ever computer science graduate
from his university.
Unfortunately, as he's registering for his final semester
of classes, he realizes that his two remaining courses
are both scheduled that basically the same time.
But surprisingly, he was able to register just fine.
At the time, the scheduling system only checked
whether classes were at the exact same start time,
not whether they overlapped at all.
So he registered for both classes,
and thought, "Problem solved, I'm in."
The student may, or may not have
actually been attending his classes regularly anyways,
so how one can be present in two simultaneous classes
was not at top-of-mind.
And a quick look at the course syllabi revealed that
between 10 and 15% of the points were for attendance.
This means that missing half, or even all of the lectures
shouldn't have been the end of the world.
It wasn't until the week before classes started that
he decided to look more closely,
and he was surprised to find a new policy that
students with more than six unexcused absences
would not be allowed to pass the course.
They would have to retake it.
Well, this was an issue,
because he was so close to graduating,
and he was about to set a record after all.
So he started thinking about how these courses
actually enforce their attendance policies.
What do these large universities use to keep track
of attendance for thousands of the students?
Well, it turns out that this is what they use.
It's an RFID-based polling system
that has become increasingly popular at universities
due to the ease of conducting attendance
for even large classes with hundreds of students.
Every student in the course will be assigned one of these,
a remote with a unique identifier
linked to their student account.
Then throughout the lecture, instructors will ask
multiple choice questions, and have students respond
by pressing the corresponding button on their remote.
The remote will then broadcast their answer
along with their student ID back to the base station,
so that after class instructors can generate
a list of students in attendance,
along with the answer they chose.
So it actually serves a dual purpose,
both enforcing attendance by requiring students
to actually show up with their remote,
but also serving as a small quiz each lecture
to make sure students are paying attention.
Well, it would seem that this system should
make it impossible to attend two lectures at the same time.
Even if a student were to give his remote to a classmate
to answer for him in one of the lectures,
he then wouldn't have the remote to answer with himself
in another lecture.
So if he's gonna make this work, he better get creative.
What he could do is try attending one class,
then attending the other class,
alternating which one he attends and which one he misses,
but that only gets him 'til the end of February
until he's used up all his drops,
so that doesn't exactly work.
Okay, but maybe he could try clicking in in one class,
then sprinting across campus to the other lecture,
and clicking in there,
then sprinting back before the next question starts.
But our mystery student isn't exactly Usain Bolt,
so that one might not work either.
What he really needed was a Time-Turner.
It's this magical device from the "Harry Potter" series
that the students used to take two classes at the same time
by time traveling.
Now, without the luxury of magic,
he would need the next best thing,
which is of course, hacking,
specifically hacking this system,
the one that actually enforces his attendance.
If he can get this system to mark him present
in both classes, he would in effect be
in two places at once.
Well, the bad news is that this remote uses
completely proprietary hardware
and software to communicate with the base station.
The good news is that hackers exist,
so of course, it was quickly reverse engineered
by some colleagues of mine at Cornell.
I've added some links here to their original paper,
and it's definitely worth a read,
but for now, I'm going to outline the techniques
they used to approach reverse engineering this system,
and then I'll explain what they found,
and how it could be exploited by our hypothetical student.
This is actually a fairly simple device
with only two significant ICs,
the first being an eight-bit micro-controller
manufactured by NXP,
and the second being a 915-megahertz ISM transceiver
manufactured by Semtech.
All one has to do to monitor the communications
between these two components is tap into the data pins
for the SPI bus here,
which is exactly what my colleagues did to sniff the data
in transit between the two ICs.
It's important to note that the manufacturer of this device
prevented the firmware from being directly analyzed
by burning the security program fuse.
They didn't, however, do this
on an earlier version of the device,
so that firmware is now available online.
Another thing my colleagues did was just packet sniff
the RF signals to see what the device was emitting directly.
A waterfall plot for the answer A is shown here.
It seems like the device is just broadcasting
a single short packet for each response
using 2-FSK modulation
at a bit rate of 152 kilobits per second.
The base station then sends back
a single acknowledgement packet,
although this is less important for our use case.
The base station and the remote appear to negotiate
a single fixed frequency for transmitting
and one for receiving, depending on what channel
they're set to use, although in practice,
it's almost always just AA.
Now, knowing the frequency and the encoding scheme,
the researchers simply pressed each of the buttons
A through E, and observed what the contents
of the resulting answer packet were, which are shown here.
Surprisingly, the packets that the remote sends
to the base station are just five bytes long,
which is just barely enough space to encode
a device serial number and an answer with maybe a checksum,
so there can't be that much more than that going on.
Additionally, only the final two bytes of each packet
actually change when the answer changes,
so this must be the portion of the message
which encodes the selected answer.
The first three bytes of the packet are always the same,
which must mean that this is the portion
that encodes the device ID,
so let's look at this part first.
It turns out that what's happening here is
just a basic transposition cipher
that shuffles the bits of the device ID
according to a predetermined and easily reversible system.
It also turns out that the device IDs,
which have eight hexadecimal digits,
contain a rudimentary built-in checksum,
whereby the fourth byte is just the xor
of the first three bytes.
Just by reversing the process in this table,
we can now construct the first part of the answer packet
for any valid device ID.
Now, let's look at the last two bytes of this message.
The fourth byte of the message just encodes
the answer choice according to a predetermined table,
and the fifth and final byte is a checksum
of the entire message according to this algorithm.
We now have everything we need
to reconstruct the entire protocol, which is shown here.
All that's left to do is to build a device
that can emulate the legitimate remote,
and it turns out that this $25 Adafruit Feather M0 board
has all of the hardware necessary to accomplish this.
The firmware that I wrote to emulate the polling system
is linked here along with a tutorial
for how to set it up.
The entire firmware compiles down to less than 10 kilobytes
and can comfortably reside
in the Arduino's built-in flash storage.
But enough talking about it, let's see it in action.
All right, now for a brief demo.
On my left is the legitimate polling system,
and as always, if I select an answer on my remote,
it'll be broadcast, and received by the base station.
On my right is an Arduino running the custom firmware
and initialized to a random serial number.
It's connected to my laptop right now with the USB,
so I can manually send it commands,
and if I instruct it to broadcast an answer
as if it were a remote, right now it'll look
to the base station as though
another student is submitting an answer using their remote.
Now, let's try this again,
but this time I'm going to set the Arduino
to the same serial number as my remote.
Now, if I click in with the remote as normal,
and then instruct the Arduino to broadcast an answer,
it appears to the base station as though
the same student is simply changing their response.
In effect, these two devices are acting
as if they are the same remote.
As it stands though, this only addresses half our problem,
because although our student would now be able
to transmit answers as if he were using a real remote,
he still wouldn't know which answer choice was correct
without being physically present,
and frankly, even then it's questionable.
Luckily, by reverse engineering this protocol,
it becomes as easy to emulate a base station
as it is a remote, simply by setting the packet radio
on the M0 to receive mode, rather than transmit.
This would then allow him to see
what other students are answering,
and simply choose the most popular response.
Okay, same demo as before, except this time,
my Arduino is set up to emulate a base station.
So when a student submits an answer,
it's overheard not just by the legitimate base station,
but also by the Arduino, which can then nicely display
all of the student selections on my laptop.
All right, well, obviously we don't want
to have to keep manually controlling this device.
Luckily, if we combine the last two demonstrations,
it's not hard to imagine a fairly basic protocol
for automating this process.
We should start by instructing the device to remain idle
until the expected start time of the class.
Then it should turn on,
and start emulating both a base station and a remote.
It should wait until a flurry of radioactivity occurs,
indicating the likely start of a new question.
It should then use the base station emulator to determine
what the most popular student response is,
at which point it should use the remote emulator
to broadcast that same response.
It should repeat those steps until the expected end time
of the class, thereby answering every question,
and most of them correctly.
So now we're getting somewhere,
but this is not exactly a practical solution.
It has to remain tethered to a PC and manually controlled.
The first step towards a completely self-contained solution
is to attach a standalone input device,
which I've done here by crudely soldering
on a 128 by 32 pixel OLED screen with three input buttons.
The really nice thing about using
an ultra low power platform like Arduino is that
this device, even with a display attached,
has a peak current draw of about 20 milliamps,
as you can see here,
so this tiny 500 milliamp hour lithium polymer battery
should last well over 24 hours on a single charge.
If I connect this up, we now have something resembling
a practical self-contained device.
Here's the same device,
just with a little electrical tape added
to hold everything together.
This finished device is what I call my Time-Turner.
It bears not much resemblance to the original,
but it can achieve many of the same results.
Let me show you.
The most basic thing I can do with this Time-Turner device
is just submit a vote as if I were using
a legitimate remote.
As you can see, the base station here
still can't tell the difference.
Another thing I can do is view the votes of my classmates.
It might be hard to see this screen,
but no matter which option I choose
on this legitimate remote, it is automatically displayed
on the Time-Turner.
Now, if I were more nefarious, what I could do is
try to change the votes of my classmates.
I'm going to restart the poll here.
And this time, no matter what my classmate chooses,
their vote will automatically be changed to B.
Let's try picking an answer.
And no matter what I choose,
it is automatically overwritten by the Time-Turner device.
Now, a vulnerability that allows me to change
someone else's vote on a so-called polling system
is a major oversight.
But if I were more nefarious still,
I could simply perform a denial-of-service attack.
Submitting hundreds of votes per second will
quickly overwhelm the host device,
eventually causing it to crash,
and making it impossible for a legitimate student
to submit their vote.
Let's restart this poll one last time
to show the most relevant type of attack,
which is simply copying the most popular vote
for any given question.
So I'm going to restart the polling,
and this time, the Time-Turner will just copy
whatever the most popular vote is.
So let's say I vote for A as a legitimate device.
The Time-Turner immediately copies that.
If the most popular vote changes to something else,
the Time-Turner will eventually change its vote,
always making sure to stay within the majority.
The idea is that with just a little adhesive putty
the student can go in the previous night,
and covertly attach this device to some surface
in the lecture hall,
and he can be sure that the next morning this device will
attend class for him while he attends the other class
the normal way.
Of course, if he can do this,
then he could just as easily build two devices
and attach them both the surfaces in the lecture halls,
and then these will both attend class for him,
and he can catch up on homework, or sleep in.
Now, I'm not gonna tell you if this student
eventually just built these for all of his classes,
but I'll let you come to your own conclusion on that one.
What I can tell you is that this device was
pretty darn effective, and by mid-semester,
the student had almost full points in both attendance
and quiz correctness.
So what does that tell us about this?
First of all, it's a great lesson about authentication.
You may already know that an authentication mechanism should
either be something you know, like a password,
something you have, like a universal second factor key,
or something you are, like your biometric data.
These factors are all in theory unique to you,
but this is just a polling device.
It's being used incorrectly
to authenticate someone's physical presence at a lecture,
when in fact there is no real authentication
happening here at all.
It's just broadcasting an answer
and an ID number in plain text over a radio signal.
Now, to their credit, hey did try to hide this
by using a proprietary protocol
that shuffles the bits around.
But I mean, this is an obvious violation
of Kerckhoffs's principle, which states that
a system should be secure,
even if everything except the key is public knowledge.
When using security through obscurity,
it's only a matter of time
until someone completely reverse engineers your system,
and what little security you had disappears.
So now that the security flaws of this particular system
have come to light, let's talk about
the various shortcomings of its design,
and how they might be addressed.
I think the flaws of this system map cleanly
onto the three so-called CIA properties,
which are Confidentiality, Integrity, and Availability.
I'll recount what I see as the core issues with this system,
and then propose a simple way to fix each of them.
First, with regards to confidentiality,
there is none to speak of as I demonstrated
when we were able to listen into other students' answers.
Next is integrity, and again, because I was able to build
a device that could indistinguishably emulate
my own, or anyone else's remote,
and even change other people's answers,
the integrity of the answers received
by a base station cannot be assured.
And finally, with respect to availability,
I demonstrated a simple denial-of-service attack
that would make it difficult
for a legitimate remote to be heard.
And now, as promised, some proposed solutions,
starting with availability.
This one is pretty straightforward.
Every single remote in a classroom is transmitting
and receiving on the exact same frequencies.
For the default AA channel,
that's about 916.5 and 903 megahertz respectively.
One would actually expect far more natural collisions
and packet drops if each honest remote wasn't broadcasting
just five bytes at a time.
But it does make this system particularly vulnerable
to denial-of-service attacks as we saw.
Perhaps a better idea would be to use FHSS,
whereby the frequency used by a given remote
rapidly changes in a way that is predictable
to the base station, but not to any passive observer.
Standardized protocols like Bluetooth
already implement this by default,
and that's for a good reason.
It's still not impossible to jam,
but it becomes much harder,
and requires wide spectrum radio frequency jamming,
which is very expensive, and very illegal.
That's not to say that any of these attacks are
particularly legal if you're not using your own system,
like I am here.
Next, confidentiality, which is also not too tricky,
one way to address this would be for the base station
and remote to perform an authenticated key exchange
when they first establish a connection,
and then use the symmetric session key
to encrypt all communications moving forward.
Something like mutual auth TLS could be used to do this
in a standardized way.
In fact, the chip used by this device
already has built-in hardware support for AES encryption,
but it was intentionally disabled for whatever reason.
And again, standard protocols like Bluetooth would
already do this by default,
although the mechanism there is a bit more intricate.
Finally, integrity, this is the trickiest problem to solve,
but one idea might be to use
a Physically Un-cloneable Function, or PUF,
a laser-based design, as shown here,
but silicon PUFs can be had for a few dollars,
and it would make it nearly impossible for me to build
another device that replicates the behavior of my remote,
or the remote of any other student for that matter.
This still doesn't solve the broader problem
of authenticating physical presence,
due to the possibility of relaying answers
from a legitimate device to one, or more remote locations.
To combat this, you would need to add
a challenge response mechanism with a tight time window,
just large enough for devices in close proximity
to submit a response, a matter of microseconds,
but not nearly what it would take to actually
relay a message over the internet,
which would be at least a few milliseconds.
A student, or at least their real remote,
would therefore have to actually be in the room
in order to respond to the challenges sent
by the base station fast enough
for their attendance to count.
All right, let's summarize.
It's hard to overstate how vulnerable this system is,
and it's even more shocking that this exact model
is currently used at over 1,100 universities,
and in nearly 100,000 classrooms.
To summarize my security recommendations,
if a new version of this system were released,
they should consider using FHSS
to avoid denial-of-service attacks,
and use encryption in transit to protect confidentiality,
bonus points if these first two problems are both solved
by simply using an open source standard,
which satisfies Kerckhoffs's principle.
Lastly, they should use a PUF
with a time challenge response mechanism to produce
what would then be an incredibly secure device,
especially by comparison to its current form.
Well, it turns out that the authentication problem
may be even worse than it seems.
That's because in addition to the student remote,
the same company also produces an instructor remote
that allows teachers to start and stop polling,
show and hide the poll results,
switch slides on a PowerPoint presentation,
and even select the correct quiz answer.
Now, if these devices look similar,
that's because they're actually identical under the hood.
So it's as easy to emulate this instructor remote
as it was to emulate this student remote,
and once one can do that,
they can do everything from changing the slides
on the instructor's presentation
to even selecting their own quiz answers as correct,
which really emphasizes the need for a PUF,
or some other hardware-based authentication mechanism.
Now, it needs to be emphasized that PUFs
and Bluetooth chips are already
bulk-produced commodity hardware
that cost a few dollars at the most.
After all, this is a $54 device,
so it's hard to argue that
there is a major cost barrier here.
By the way, this one is about $30
if you already have a soldering iron.
As for our canonical student, well, as I mentioned,
all of this was taking place in the spring of 2020,
and around the same time,
another major world event was starting to unfold.
So of course, midway through the semester,
he ends up receiving this email,
which among other things tells him that
all of his classes have been moved online,
and that all students will get full participation points.
So while this didn't end up being helpful,
hopefully it at least made for an interesting DEF CON talk.
As for these days, well, if a student wanted
to attend two classes at once today,
this is how they would do it.
Thank you.