N.I.R.E.M.A.
NFC Implant-base RSA Encrypted Messagging application
This project aims to develop an NFC implant-based RSA encrypted messaging application that ensures secure communication between the users and lets the user be the only one who can decrypt the exchanged messages. Besides secure transmission, this application focuses on saving the user private key on an external underskin implant. Thanks to the Mifare DESFire chip’s security, the user can keep out-system the private key used to sign and encrypt the communications. Therefore, the only way to access the messages will be with the possession of the unique implant.
Installation steps on Linux Debian base
- Setup proxmark3 client and firmware
- Installation Server Side
- Installation Client Side
- Start the server
- Start the client
Hardware required
Documentations
- N.I.R.E.M.A. file structure
- Registration
- Login
- Chat GUI
- MIFARE DESfire structure
- Request schema
- Application flow
- Database structure
- Creation of a DESFIRE MIFARE app
- Credit
Proxmark3 client version
ATM this application is not working with the last version of the Iceman proxmark firmware. (There are problems related to the dinanic memory). HERE there is the last tested working version, released 20,2021 (ea80ea2).
The proxmark firmware and client should be matching every time. But as I have tested the firmware of the 4-11-2021 with the client of the 20-5-2021, I can confirm that it is working for this occasion. ( I am explain that so if you have a proxmark3 with the last firmware you do not need to reflash it with an old one.)
Installation Server Side (Linux Debian base)
- cloning the repo
git clone https://github.com/Kaosxx88/NFC-Implant-base-RSA-Encrypted-Messaging-Application.git
- cd in the folder
cd NFC-Implant-base-RSA-Encrypted-Messaging-Application.git
- python 3.7+
sudo apt-get install python3
- pip3
sudo apt-get install python3-pip
- Requirements Installation
python3 -m pip install -r requirements.txt
Installation Client Side (Linux Debian base)
- cloning the repo
git clone https://github.com/Kaosxx88/NFC-Implant-base-RSA-Encrypted-Messaging-Application.git
- cd in the folder
cd NFC-Implant-base-RSA-Encrypted-Messaging-Application.git
- python 3.7+
sudo apt-get install python3
- pyqt5
sudo apt-get install python3-pyqt5
- install python3 pip
sudo apt-get install python3-pip
- Requirements Installation
python3 -m pip install -r requirements.txt
IMPORTANT
The file 'pmx3_read_keys_from_desfire.py' in the client folder of the repo, need to be modified accordly. In line 22 the variable self.pm3_path must be change to the user path where the proxmark client have been dowloaded.
Kali linux ONLY
(Setting up a virtual environment top avoid conflict with the python3 modules "serial" / "pyserial" )
- installation of virtual environment
sudo apt-get install python3-venv
- creation virtual environment
python3 -m venv path/to/the/folder
- activation of the virtual environment
source /path/to/the/environment/bin/activate
Start the server application
- change directory into the repo
cd /path/to/the/repo
- change directory into the server folder
cd server
- run the file server.py
python3 server.py
Start the client application
- change directory into the repo
cd /path/to/the/repo
- change directory into the server folder
cd client
- run the file ui.controller.py
python3 ui_controller.py
proxmark3 The Proxmark is one of the most must-have of a hacker inventory. It is a cards reader that can read, write, force, and simulate many different types of chips on the market. In this project, the proxmark3 easy have been used to read and write the keys on the MIFARE DESFire chip.
ACR The ACR122U is a card reader able to communicate with the MIFARE DESFire chip using the Application Protocol Data Unit called ADPU. This device has been used to change the standard key of the chip MIFARE DESFire. The sample DESFire cards have been bought directly from an abroad supplier, and they come with a standard key formed of all 0 digits.
MIFARE DESfire The Mifare Desfire chip is one of the most secure chips in the market right now (the same chip that is present on the card of the London Underground, known as Oyster Card ). It offers an Advanced Encryption Standard of 128 bit and has enough storage capacity to store a public key pair of 4096 bit. The same chip has been embedded in an implant from a company called [Dangerous things](https://dangerousthings.com/) .
N.I.R.E.M.A. file structure
Registration The Nirema registration screen has three main buttons that can be pressed. The first one, called “Create a new key pair,” helps the user create new keys if he does not own them already. The second button, called “ Load key pair from files”, allows the user to select the key from a user-chosen folder. The last button, called “ Load key from DESFire”, allows the user to load the keys directly from the MIFARE DESFire chip
The first and the second button are bringing the user to two different pages, but they are almost the same in graphical. In the following picture, there is a comparison of them. On the left one, the user has to choose the path to save the keys, and on the right one, the user has to select the path from where to load the keys.
Both of the above screenshots show the need for the passphrase location to encrypt or decrypt the private key. The back and next buttons are helping the user to move in between the registration process. If the user selects the load key from the DESFire button, the screen on the left picture will appear. As in the login screen, the COM port will be automatically detected, and the first one available will be set as the default one. The user will be able to change the default port with another one by clicking on it and selecting another port to use. Elements 2 is the passphrase entry for the private key. Without it, the application will not be able to load the key in the system.The three previously explained application screens are bringing the user to the final part of the registration. In this section, point 1 shows the rules to follow in the nickname selection. Point 2 is where the user has to input the nickname that he wants to use. The registration button on the left side of the image, once pressed, will send the registration request to the server, and if the chosen name is available, the registration process will be authorised and completed. At this point, the left screen will appear. The top label will show a congratulations message to the user, and the bottom label will confirm the correct registration of the user. After the registration process is concluded, the user will be redirected to the login screen, and he can finally log in to the Nirema application. The following image shows the pseudocode of the registration process. The pseudocode is an informal language that helps the programmer to develop the algorithm. It is giving a better understanding of the registration code behind the user interface. It is crucial to keep in mind the final code is much more complex.
Login
The first screen of the Nirema application is the log in one. There are many elements; let’s take a look at all of them one by one. Points 1 and 2 are the user nickname and the private key passphrase input; the 3 and 4 are the tabs selection for the upload method of the keys. The NFC tab allows the user to load the keys by scanning the MIFARE DESFire chip. On the other side, the File tab, let the user search for the keys in the system directory (There will be another screenshot explaining this part). Point 5 show the available COM port connected to the system. This is the port where the Proxmark or any other card reader will be connected. Point 6 is the login button, and point 7 redirect the user to the registration screen.
Chat GUI
- Application logo
- Name and version of the application.
- Logged user nickname.
- Entry to search for new users
- Button to send the request to the server to search the new user.
- Label that shows an intro message to the user with instruction
- Instruction label
- The top chat label will show the selected chat user destination.
- The delete button, delete all the conversation with the user from the server.
- The search button, search in the chat any corresponding text.
- The message entry allows the user to write the message.
- The left user list shows all the linked user and conversation in the account
- The send button sends the message and clears the message entry.
- The Chatbox will display the conversation.
- The clear button will clear the message entry box.
- New message notification
- New user on the user list
MIFARE DESfire structure
The MIFARE DESFire chip can store up to 28 different applications; each application can have up to 32 files between standards, backup, value file, record file and cycling recording file. Each Desfire chip has a card master key, and each application on it have a maximum of 14 different keys that can be assigned to write, read and delete data in the chip (NXP, 2015). For the realisation of this project, two applications have been written to the DESFire cards. The first one with the Application ID number 0x888888 has been assigned to the public key, and the second application with the AID 0x999999 has been allocated to the encrypted private key. The picture on the left side shows the enumeration of the Desfire chip using the proxmark3 easy. It is possible to notice the two applications written on the chip ( Green arrow). Each of them has one file with the keys inside ( Blue arrow). The files have free read permission but need a predefined key to be written on the card to avoid any unauthorised alteration (Orange arrow). All the keys and the linked authorisation are customisable on the application and file creation. When read from the smart card reader, the internal structure of the MIFARE DESFire chip will be displayed as in the following picture. Please keep in mind that the next image only shows part of the saved private key.
As is possible to notice from the picture above, the displayed memory is around 240 bit ( left bottom corner). To give an idea of the private keys’ real size, the number of 240 bit has to reach 3296 bit. Therefore the saved key will be more or less 14 times longer than the sowed picture. The same idea must be applied to the public key representation, but it will reach only 784 bit of size. The two keys added together will form a public key pair 4096 bit. Therefore it is simple to understand that a lot of data have been written to the card.Requests schema
The server side of the Nirema application is in charge of handling the requests and the connections coming from the clients. The servers configuration allows it to accept only specific requests and reject the not recognised or unauthorised ones. The following schema shows the requests of the server.
As is possible to notice in the above picture, all the requests and responses are encrypted apart for the public key request. It is essential to keep in mind that the server uses SSL/TLS certificates. Therefore even if the public key request is not encrypted directly, it is encrypted at the socket level. The symbol (PK) on the above schema’s encryption section means that the communication is encrypted using the counterpart public key and signed using the sender’s private key. Using this encryption method, the recipient of the request/response is sure of the authenticity and the confidentiality of the content. The symbol (RSA) means that the communication is encrypted using RSA at a 256-bit algorithm based on a shared secret key.
Analysing the above request, the utmost level is the SSL/TLS certificate, which protects its content. At the current moment, the server uses a self-signed certificate, but on the day of the Nirema lunch, it will be necessary to buy a certificate for the domain. The second level is the RSA 256 bit encryption. This encryption is based on a secret exchanged between the server and the client on the public key request. Inside the kernel of the request, there are five elements. The first one is the nickname of the recipient of the message. It is needed for the server to redirect the message to the correct user. Therefore the server needs to be able to read this information. The other four elements are not being decrypted from the server because the server does not have the private key to do it. The only way to decrypt the encrypted messages is to be in possession of the sender or recipient private key. Talking about the last four elements looks like they are present twice on the request. It is accurate, but for a reason. For the sender of a message to be able to download the conversation from the server in the future and do not keep the conversation decrypted locally, it is needed to keep on the server a copy of the message that he can read and decrypted. In the case that only the version of the message that is destinated to a recipient is kept on the server, the sender will not be able to decrypt it anymore because only the recipient’s private keys can do it.
Application flow
The above picture shows the concept flow of the N.I.R.E.M.A. application. The utilisation of the local public key database and the (public) public key database NEED TO BE IMPLEMENTED as 2FA and 3FA.
Database structure
The above image show the structure of the server database in which the message are stored. The structure is former of:
- Message number
- Sender Nickname
- Recipient Nickname
- Message encrypted with the sender public key
- Message sign
- Message encrypted with the recipient publick key
- Message sign
Creation of a DESFIRE MIFARE apps
(WORK IN PROGRESS)
Colors and logos
The color palette has been inspirated from Kali Linux theme design ( 2020.1). The following N.I.R.E.M.A. logos are available on the client side folder.
Credits
A big thanks go to Fausto Fasan for the N.I.R.E.M.A. application logos