MagicBands Can Be Read By NFC Enabled Phones

[PirateFuzzball]

The MagicBand has a NXP Semiconductors MIFARE DESFire EV1 tag and appears to have 512 Bytes of storage. It was scanned with a SGS4 which has a Broadcom BCM20794 NFC chipset. None of the serial numbers on the band matched the info that I was able to obtain from the tag. It does have a couple of sections that require an encryption key to access. It took about a second for my phone to read it; the wife's SGN2 with the NXP PN544 NFC chipset seemed to read it a few milliseconds faster. I used both NXP Semiconductors' NFC TagInfo and NFC Research Lab's NFC TagInfo apps to scan it.

My wife asked me to scan our bands, hop on here, and let you guys know. I don't frequent these forums much so please pardon me if my responses aren't prompt. Please know that I will not be attempting to write any data to our bands nor will I invest the time to break the encryption.

I don't have time to take a bunch of screen shots and upload them so below is the NXP's app output from the scan in XML format. I have X'd out the last four of any identifiable information.

<?xml version="1.0" encoding="UTF-8"?>
<scan>
<version>2.00</version>
<date>2013-09-12</date>
<title>NXP Semiconductors MIFARE DESFire EV1 tag</title>
<uid nxp="true">04:4D:35:XX:XX:XX:XX</uid>
<hasndef>false</hasndef>
<section>
<subsection title="IC manufacturer">
<block type="text">
<content>NXP Semiconductors</content>
</block>
</subsection>
<subsection title="IC type">
<block type="text">
<content>MIFARE DESFire EV1</content>
</block>
</subsection>
<subsection title="DESFire Applications">
<block type="text">
<content>Access control data for electronic locks #0
¶ Timelox AB<hexoutput> (0xF70090)</hexoutput>

and 1 unknown application<hexoutput>:
¶ Unknown application 0x78E127</hexoutput></content>
</block>
</subsection>
</section>
<section>
<subsection title="No NFC data set storage">
<block type="text">
<content></content>
</block>
</subsection>
</section>
<section>
<subsection title="Memory information">
<block type="text">
<content>Size: 0
kB
Available: 320 bytes</content>
</block>
</subsection>
<subsection title="IC detailed information">
<block type="text">
<content>Capacitance: 70
pF</content>
</block>
</subsection>
<subsection title="Version information">
<block type="text">
<content>Vendor ID: NXP<hexoutput> (0x04)</hexoutput>
Hardware info:
¶ Type/subtype: 0x01/0x02
¶ Version: 1.0
¶ Storage size: 512 bytes<hexoutput> (0x12)</hexoutput>
¶ Protocol: ISO/IEC 14443-2 and -3<hexoutput> (0x05)</hexoutput>
Software info:
¶ Type/subtype: 0x01/0x01
¶ Version: 1.4
¶ Storage size: 512 bytes<hexoutput> (0x12)</hexoutput>
¶ Protocol: ISO/IEC 14443-3 and -4<hexoutput> (0x05)</hexoutput>
Batch no: 0xBA3494XXXX
Production date: week 24, 2012<hexoutput> (0x2412)</hexoutput></content>
</block>
</subsection>
</section>
<section>
<subsection title="Technologies supported">
<block type="text">
<content>ISO/IEC 7816-4 compatible
Native DESFire APDU framing
ISO/IEC 14443-4 (Type A) compatible
ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible</content>
</block>
</subsection>
<subsection title="Android technology information">
<block type="text">
<content>Tag description:
¶ TAG: Tech [android.nfc.tech.IsoDep, android.nfc.tech.NfcA]
android.nfc.tech.IsoDep
¶ Maximum transceive length: 261 bytes
¶ Default maximum transceive time-out: 1000
ms
¶ Extended length APDUs not supported
android.nfc.tech.NfcA
¶ Maximum transceive length: 253 bytes
¶ Default maximum transceive time-out: 1000
ms
No MIFARE Classic support present in Android</content>
</block>
</subsection>
<subsection title="Detailed protocol information">
<block type="text">
<content>ID: 04:4D:35:XX:XX:XX:XX
ATQA: 0x4403
SAK: 0x20
ATS: 0x0675778102XXXX
¶ Max. accepted frame size: 64 bytes (FSCI: 5)
¶ Supported receive rates:
" 106, 212, 424, 848
kbit/s (DR: 1, 2, 4, 8)
¶ Supported send rates:
" 106, 212, 424, 848
kbit/s (DS: 1, 2, 4, 8)
¶ Different send and receive rates supported
¶ SFGT: 604.1
µs  (SFGI: 1)
¶ FWT: 77.33
ms  (FWI: 8)
¶ NAD not  supported
¶ CID supported
¶ Historical bytes: 0x80 |·|</content>
</block>
</subsection>
<subsection title="Memory content">
<block type="text">
<content>PICC level (Application ID 0x000000)
¶ PICC key configuration:<hexoutput> (0x0F01)</hexoutput>
  " AES key
  " PICC key changeable
  " PICC key required for:
    ~ directory list access: no
    ~ create/delete applications: no
  " Configuration changeable
  " PICC key version: 254</content>
</block>
<block type="text">
<content>
Application ID 0xF70090
¶ Key configuration:<hexoutput> (0x0B83)</hexoutput>
  " 3 AES keys
  " Master key changeable
  " Master key required for:
    ~ directory list access: no
    ~ create/delete files: yes
  " Configuration changeable
  " Master key required for changing a key
  " Key versions:
    ~ Master key: 0
    ~ Key #1: 0
    ~ Key #2: 0</content>
</block>
<block type="text">
<content>¶ 1 file present</content>
</block>
<block type="text">
<content>
  " File ID 0x00: Standard data, 128 bytes
    ~ Communication: encrypted
    ~ Read key: master key
    ~ Write key: master key
    ~ Read/Write key: master key
    ~ Change key: master key</content>
</block>
<block type="text">
<content>    ~ (No access)</content>
</block>
<block type="text">
<content>
Application ID 0x78E127
¶ Key configuration:<hexoutput> (0x0B82)</hexoutput>
  " 2 AES keys
  " Master key changeable
  " Master key required for:
    ~ directory list access: no
    ~ create/delete files: yes
  " Configuration changeable
  " Master key required for changing a key
  " Key versions:
    ~ Master key: 1
    ~ Key #1: 1</content>
</block>
<block type="text">
<content>¶ 2 files present</content>
</block>
<block type="text">
<content>
  " File ID 0x01: Standard data, 16 bytes
    ~ Communication: plain
    ~ Read key: free access
    ~ Write key: free access
    ~ Read/Write key: blocked
    ~ Change key: free access</content>
</block>
<block type="text">
<content>    ~ Contents:
</content>
</block>
<block type="DesFire">
<address addrwidth="4">0</address>
<data>68 8C 1F 00 00 00 00 00 05 FB 00 05 XX XX XX XX</data>
</block>
<block type="text">
<content>
  " File ID 0x02: Standard data, 56 bytes
    ~ Communication: plain
    ~ Read key: key #1
    ~ Write key: free access
    ~ Read/Write key: blocked
    ~ Change key: free access</content>
</block>
<block type="text">
<content>    ~ (No access)</content>
</block>
</subsection>
</section>
</scan>

 

[rock_doctor]

Interesting. As time progresses on I think there will be many that will reverse engineer the magic bands. I look forward to see what they come up with. Thanks

 

[wiigirl]

Very interesting....

 

[artesian]

Interesting and maybe alarming?

 

[the who #3]

do you worry about credit information being obtained by the wrong person?

 

[kaylasmom07]

Pardon my ignorance but I'm confused. What does this mean? Are you able to read personal information from the bands using the scan on your phone?

 

[anthony2k7]

Pardon my ignorance but I'm confused. What does this mean? Are you able to read personal information from the bands using the scan on your phone?

I think the answer to that is no, there is unlikely to be anything personal on the band.

However, I think this does mean that cloning someone elses magic band (for charging to room, or even accessing a room) is worryingly close to being possible already.

I cant believe Disney went for RF technology which is so easily readable when they're spending however many billion on this whole project. Almost every mobile phone will have NFC support in the next couple of years, coupled with ever increasing CPU speeds, on phone cracking and cloning could quickly become possible. They really should have gone for a more proprietary system I think.

I'll be the guy in the park with aluminium foil wrapped around my magic band I think!!

 

[PirateFuzzball]

Interesting and maybe alarming?

In the grand scheme of things, there's little to worry about. It would be silly to wear the band outside the park and isn't any less trackable than the other RFID tags being put into many other things. On a simple scan, only a few unique numbers can be read and they don't mean a whole lot. There's an encrypted section that is probably what Disney is using to store the more identifiable information in their closed system. My understanding of the DESFire EV1 is that it requires an encrypted handshake and we don't have access to Disney's encryption keys. Plus if one were to invest the thousands of dollars into the appropriate equipment, there are more profitable things one can do than scanning MagicBands.

Is it 100% secure, no and nothing really is anyways. The only real secure system is one that is encapsulated in an impenetrable box and isn't connected to anything; basically it's just a matter of time, resources, and dedication to break encryption. The original DESFire tag was compromised a few years ago partially because they were using 3DES. DESFire EV1 uses AES which isn't completely broken yet, but IIRC it takes some investment in processing power for at least a brute force attack with 256 bit and smaller keys. The NSA supposedly has a way to break AES encryption, but that hasn't been completely confirmed yet.

I would find it highly dubious if Disney put one's address and credit card number in the MagicBand's encrypted storage. In a PCI DSS audit I don't think having the credit card data in there would fly even if it was encrypted. More than likely any credit card data is secured in Disney's servers where they have more control over the encrypted data.

If one were to worry about RFIDs, worry about credit cards that have RFIDs and how easily it would be to steal that information, the data that is kept on one's passport, and the data that's on one's state ID. I would be more concerned with the data mining on me done by every single company I do business with than one RFID chip that could be used to triangulate my location in a theme park that I'm going to attend for a week.

 

[PirateFuzzball]

Pardon my ignorance but I'm confused. What does this mean? Are you able to read personal information from the bands using the scan on your phone?

The code box of my original post contains all of the information I was able to obtain from the MagicBand. There is no private information as you can see. I went ahead and obfuscated the two unique numbers and the manufacturing batch number since this is going on the internet; I probably don't have to, but did it anyways. One would need to have access to Disney's private system to match up any serial number to the private information they have on me (address, DOB, CC, etc) and I wouldn't be surprised if the numbers that can be pulled via a casual scan, like the one I did, are not associated with that data. If they were smart, they would use a separate serial number that is stored in the encrypted area and nothing else.

It would be foolish of Disney to store any private information in a device that is outside of their control. As I mentioned in a previous post, I doubt a PCI DSS audit would allow credit card information to be stored on a MagicBand.

 

[ParrotBill]

Disney has already said they won't store personal information on the band. There will be no information about you or your credit card or your park ticket.

But the band is an identity that has been tied to your MDE account and any tickets, reservations and other info you have stored or linked there.

I do so some worrying things in this data dump.
There is an open writeable data area. I assume this will be used by some future "fun" activity planned or yet to be conceived. You could pick up some temporary data at the beginning of a ride that would be used again at the end of the ride, for example.

The other areas require encryption keys to access. If those keys get broken or leaked, unscrupulous persons could read or modify that data with a device in a bag sitting next to you on a bench.

Cloning should be the biggest issue. It seems easy to me to take this data and burn it to an equivalent chip, then place it into a magic band and pretend you are the person you just cloned.

I hope Disney's system is ready to glow "red" when it detects a second entry to a park. Then you'll need to show ID that you are the right person, and replace it and disable the other. Then they need an alert for a band reported "stolen" so they do a COPS style takedown of the perp. I can't wait.

But seriously, although it looks like you could clone it the PIN protects you from anyone charging, and Disney can and hopefully will detect multiple park entry use. Accessing your hotel room might be the biggest issue... if they follow you and find out where it is.

 

[gacompguy]

However, I think this does mean that cloning someone elses magic band (for charging to room, or even accessing a room) is worryingly close to being possible already.

Maybe, but I'm guessing that there are other safeguards in place. If you whip out a cloned Magic Band at DHS and the true owner is over at Epcot, it wouldn't be difficult for Disney to identify the fraud. Not to mention the fact that they'll have multiple high res pictures of your face.

I also feel the need to point out that cloning magnetic strips is incredibly easy. How often do you hear about that happening in the parks?

I cant believe Disney went for RF technology which is so easily readable when they're spending however many billion on this whole project. Almost every mobile phone will have NFC support in the next couple of years, coupled with ever increasing CPU speeds, on phone cracking and cloning could quickly become possible. They really should have gone for a more proprietary system I think.

In the industry, this is called security through obscurity. And... it doesn't work. If anything, it actually makes you more vulnerable to people hacking into your system.

I'll be the guy in the park with aluminium foil wrapped around my magic band I think!!

Depending on how you do it, you could actually be amplifying the signal!

 

[Disco]

Neat!
Didn't know they were going to be NFC! They probably should have used their own proprietary version as so they couldn't be read by the common cell phone though.

 

[starsweeper]

My DH is an electrical/software engineer. He said with an antenna small enough to fit in a backpack, he could pick up any magic band within 20-30 feet for reading and cloning.

 

[Polydweller]

My DH is an electrical/software engineer. He said with an antenna small enough to fit in a backpack, he could pick up any magic band within 20-30 feet for reading and cloning.

Not that it would o much good. The band has only a reference number, no personal info. The number doesn't get you into the park by itself. It's tied to the finger scanner. And, you need a pin for purchases. You give the pin at checkin. So, on its own meaningless. Clone away, a band won't work without the other info.

 

[Gareth& Hayley]

Disney also state they will actively read your magicband as you pass certain points. For example they could technically find out how often you go on a ride (even when not using FP+) or how much of the park a guest covers etc. And this would be done from distance.

 

[BwoZoo22]

Disney also state they will actively read your magicband as you pass certain points. For example they could technically find out how often you go on a ride (even when not using FP+) or how much of the park a guest covers etc. And this would be done from distance.

Or which restrooms see the most traffic/longest waits...

 

[SuperDan523]

Or which restrooms see the most traffic/longest waits...

I'd like to schedule a Fast pass Plus for the Oddysey men's room for Tuesday at 3:35 pm...

 

[tiki23]

I'd like to schedule a Fast pass Plus for the Oddysey men's room for Tuesday at 3:35 pm...

Hopefully there won't be any ride photos on this one....

 

[brelyt]

I'd like to schedule a Fast pass Plus for the Oddysey men's room for Tuesday at 3:35 pm...

Or maybe "SuperDan sure does go to the bathroom a lot, maybe we should send a Disney nurse to his room this evening to check on him."

 

[delilah]

Or maybe "SuperDan sure does go to the bathroom a lot, maybe we should send a Disney nurse to his room this evening to check on him."

There are Disney nurses?