Disclaimer : The information provided here is solely for educational purposes.
The system I would be looking at is the ST Electronics' ST8100 Securnet. This is an integrated security management system that includes an access control module that manages physical access to facilities. One of the smartcards supported by the system is the Mifare 1K cards. The system with the mifare card option is being used by a number of organizations including a university.
The mifare card used by the system is the Mifare Classic 1K card, also known as the Mifare S50. Specifically, it uses the older 4 byte Non Unique ID (NUID) version. Out of the 16 sectors, only sector 1 and 2 are being used. Both Key A and key B for sectors 1 and 2 have been changed while the keys for all other sectors are left at default value. Key A for sector 1 and 2 is the same. All cards have unique keys for sector 1 and 2. Personal details of the individual card holder are stored in sector 1 and 2.
Bearing in mind that the entire research was conducted in a blackbox manner, there are certain implementation details that are conjectures. It is possible to elicit 3 types of responses from the system.
- No reponse
- No such user response
- Access granted
No response - The system will not respond if the 4 bit NUID is not tied to any user in the system
No such user response - The system will respond in such a way if the user does not belong to an access group that has access to the facility
Access granted - The user belongs to an access group that has access to the facility
I have encountered situations when granting additional access did not require me to surrender my card. Hence, I believe that the access groups are stored at the backend and not the card. However, existing material from the vendor claimed that the group ID is encoded on the card itself. Furthermore, analysis of cards belonging to users from different 'departments' revealed that bytes 4 and 5 in block 5 appears to be the group id. Therefore, apart from access groups, I believe that the system allows for finer-grained control of access rights which are stored on the controller. These controls are used, in my opinion, for granting temporary access rights to a facility whereas access groups are meant for permanent access rights.
def login(4 byte NUID, facility ID) if (4 byte NUID does not exist) return if (4 byte NUID has temporary access rights to facility ID) return "access granted" else retrieve group ID (key A) // Key A is retrieved from a key-value table and is mapped by NUID. The key is required to access sector 1 and 2 if (group ID has access rights to facility ID) return "access granted" return "no such user"
Cloning the card
- UID changeable card (4 byte UID version)
- NFC dongle that is supported (I used the ACR122T)
- Linux machine
Apart from cloning the contents of the card itself, we need to clone the 4 byte NUID as well. However, the UID for ordinary cards have been burned in. We would need to get the special "chinese" cards. Searching "uid changeable" on ebay or taobao will net you some. I would advise getting the full credit card sized version. The keychain sized one has problems with some readers probably because the antennae does provide enough power for the chip.
We would first need to install libnfc and mfoc. You have might to configure, make, install depending on your distro. Next, we would use mfoc to brute force the keys for sector 1 and 2 and dump the data. It should take only a few minutes.
mfoc -P 500 -O card.mfd
Then, we will overwrite the 4 Byte UID. If the UID does not get overwritten despite carrying out this step, you might have bought a normal card instead of the UID changeable card. It is impossible to change the UID of a normal card, since it is already burned in.
nfc-mfsetuid <<insert UID here>>
Lastly, we would need to clone the binary data onto the new card.
nfc-mfclassic w a u card.mfd