Dissecting the //build/ Badge (Part 2)

A little under a month ago, I dissolved Paul Thurrott's //build/ badge to reveal an embedded NFC integrated circuit (IC). But I had to stop short of actually reading its data due to the lack of a proper NFC reader. (Windows Phone 8 doesn't give you raw NFC access.) I purchased an ACS ACR122T and after weeks of waiting and experimenting I can now complete the story.

So, let's start off with a correction. In Part 1, I incorrectly guessed that the IC was a MIFARE Ultralight. Turns out, it's an older MIFARE Classic 1K complete with key-based security. But before I wrote the IC off as encrypted and inaccessible, I learned that these ICs were compromised back in 2008 -- with a card-only attack following in early 2009.

Let's take a brief moment to talk about these keys.

Without getting too technical, these NFC ICs have chunks of data. Each chunk of data can be secured via a pair of keys -- A and B. Each of these keys can be used separately to access the data it protects. (For example, you may give a read-only key A to conference vendors, while maintaining the read-write key B for administrative purposes.)

Back to the badge.

Without access to an authorized //build/ badge reader, I had to use a software implementation (mfcuk) of the card-only attack I mentioned earlier to recover keys A and B. After weeks of painfully fiddling with the timings of the attack, I successfully recovered key B on one chunk of data. (I then made quick work of the rest of the keys/chunks using another attack [mfoc].)

Key A was recovered but isn't worth sharing because it appears to be unique per badge. (Tested with two badges.) Key A is usually programmed as a read-only key -- presumably for vendors on the conference floor. But given its uniqueness I'm confused as to how vendors would obtain a valid key at scan time. Perhaps the readers were networked to a key management system? Or maybe Key A is computed at runtime using a mash of the badge unique ID and a shared secret? Or maybe there's a handful of keys per attendee group (e.g. media, student, presenter). What do you think?

Key B is static, thankfully. On two badges I examined, Key B was given write permissions card-wide. So I named it The //build/ Badge Administrative Key. That key is f4a9ef2afc6d.

Using the Badge Administrative Key, I dumped out the entire //build/ badge. Surprisingly, it's not empty! It contains the following information:

• Two sets of identifiers(?) (6 digit, 4 digit) (e.g. 756552, 1269)
• Badge Full Name
• Badge Title
• Full address
• Phone number
• Email address
• Affiliation label, if applicable (e.g. Media)

So if you're planning to toss the badge into the trash, you may want first wipe the IC. But if you're a developer looking to dip into NFC, you may want to salvage the tag and format it to NDEF specs so you have something Windows Phone compatible to play with.

Regardless, case closed.