Archive for the ‘RFID’ Category

h1

No Reader is Trustworthy

February 12, 2013

This guy.  This guy!

The protocol stands, but yet another implementation falls.  Take this as a lesson.

Holy crap, it worked! (Of course, it was only logical that it would, but it always gives you a thrill to see that “I’m in!” moment…) And in only 10 minutes too! Out of the 4.2 million bytes in the file, there were only 53,442 unique contiguous 16 byte chunks, and our key was the 13,675th.

This is the future of hacking.  Stay alert.  Trust no one.  Keep your JTAG interface handy.

h1

I don’t share your greed…

October 16, 2012

…the only card I need is:

Here is an interesting concern for people with proximity card access control systems. Does your brand of reader have a default “backdoor” card ID that is considered valid?

You really should tear apart and check your card readers.

h1

I’m in the wrong country this week!

December 30, 2010

I missed this:  https://events.ccc.de/congress/2010/Fahrplan/events/4114.en.html

Remember where I said here: “HID’s iClass hasn’t been broken to my knowledge, and is the best bet to transition from their legacy systems”?  That’s not quite true anymore.  Standard Security Mode in iClass has been broken.   Quoting Milosch Meriac’s paper “Heart of Darkness — Exploring the uncharted backwaters of HID iClass security”:

Standard Security Mode is dead. Switch immediately to High Security by asking your local HID vendor for programming cards that will upgrade your Standard Security system to High Security and rotate your existing cards to the new keys at a trusted location only. Make sure that your vendor tells you the new High Security key.

That guy did some cool hacking to get the standard security keys.  Additionally, HID screwed up big-time in their implementation.

As a side note, I couldn’t join in the laughter here: https://events.ccc.de/congress/2010/Fahrplan/events/4036.en.html.  Someone should have read the Wikipedia page on MIFARE before they made their payment system.  The talk explains why.

h1

The eye of the enemy is gazing upon: static proximity cards

December 8, 2010

Two times in the last month, complete strangers have asked me how to clone proximity cards.  One actually framed the question in a way that implied they wanted to clone a card so they could gain unauthorized entry somewhere.  Tip:  Don’t try to include someone you don’t know in a criminal plan.

I think that ordinary criminals are becoming aware of the inherent vulnerabilities of old-fashioned static-ID proximity cards.

If you’re using cards that spit out a 26 or 32 or 84 bit value in the presence of the right LF carrier, there are threats you shouldn’t ignore.  Given the upswing in interest, “Nobody does that!” is probably no longer a viable excuse.

Cloning cards

Yes, cards can be cloned.  Easily.  You can use programmable tags, or put together easily-hidden electronics to do the deed.  If you want the card to look perfect, the biggest expense is a card printer.  Even the used ones are not cheap.  All you need to do is collect a number from a valid card.

Proximity cards are great because unlike cut keys, you can individually assign and revoke access without headaches like re-keying locks and issuing new keys to a crowd of people.  Static proximity cards are terrible because unlike cut keys, which you can only copy if you get access to one (or take a photo of it), you can make a copy of the card without the owner ever showing it or knowingly using it.  Flash the card with the right carrier frequency and out spits the card’s number.

Brute Force

Go and check your security system’s logs.  Are there any long strings of access denials, thousands in a row?  Someone may be brute forcing your system.  It’s easier than it sounds, particularly if the person doing the forcing is not particular about what valid card number trips the lock, and your lock responds to a lot of cards.  Remember that many of your ‘bits’ might be an unchanging facility code, and at least one is a parity bit.  When you have a 26 bit card system, it doesn’t take long for an attacker to stumble upon one of the 1000 cards you authorize for your perimeter locks.

It may be the case that *your* attacker doesn’t want to stand around one of your doors in the cold for six hours.  This attacker doesn’t even have the good sense to crank up the power on the ol’ brute-forcer, leave it in a backpack with a couple of “beep sensors” near the door, and pick it up later.  Maybe your attacker already has a card to get in, but wants access to an area his card won’t let him into.  Here’s where that facility code becomes an instant liability.  The attacker with the card knows what it is.

The mechanism is cumbersome, but may be worth someone’s effort for privilege escalation.

Passive Interception

If you’re going to the trouble of standing by a card reader (or leaving a backpack near a card reader), why bother *guessing* valid cards?  There may be dozens, or even hundreds of people with valid cards going through the door every hour.  All you have to do is listen to the card spit out its number.  You don’t even have to energize the card yourself…the reader five feet away does it for you.

You don’t need a six-hundred meter long quarter-wave antenna.  There are very efficient inductive antenna designs that will easily fit in a backpack or briefcase.  You can pick up low power 125Khz transmissions across a lobby.

Stupid tricks

It isn’t hard to take a card reader you bought off Ebay and set it up to collect cards independent of an actual access control system.  Stick it up next to a door and watch everyone badge themselves through.  You have to remember the “beep”, or the Pavlovian trick doesn’t work.

This doesn’t apply to us because everything *valuable* is behind doors with a card+PIN reader

The claim that anything of value is in a card+pin secured area doesn’t hold water.  Think what a single person with a roll-aboard can make off with in a large office during lunch.  Laptops, smartphones, people’s petty cash, car keys…there’s a lot of valuable things laying around the average office.  Talking about secured areas means you’re defending against a presumed attacker that is willing to spend tens of thousands of dollars to get access to your precious database servers or machine tools or your stacks of pre-assembly components.  The barrier of entry to get past the front door of a disturbingly large number of “secured” buildings is less than $500.  This means someone looking to walk off with a dozen laptops now needs to be in your list of threat actors alongside the “skilled and motivated” attackers.

What if someone isn’t looking to take something, but wants to *leave* something?  How much of your information security posture is dependent on the integrity of your physical security perimeter?  It’s not just cat burglars and petty thieves interested in breaking into your office.

So, what do we do?

Use contactless smartcards that authenticate reader and card.  Don’t use MIFARE Classic, of course.  It’s been broken for years.  NXP’s MIFARE Plus or DESFire using AES are good choices.  HID’s iClass hasn’t been broken to my knowledge, and is the best bet to transition from their legacy systems.

Too expensive!

Proximity cards are cheap.  Smartcards aren’t significantly more expensive when you take into account the actual costs of card issuance.  A $1 proximity card still has a $10-$20+ overhead of getting the card enrolled to the right person securely.  That overhead is the same when you issue a $4 DESFire EV1 card.

Plan for the future and ensure new readers can accept the technologies you want to use when you eventually crank out the smartcards.

We’re stuck with static proximity cards for now…

Don’t hand out “visitor” cards.  If you absolutely need to give people temporary cards, don’t re-use them.  If you have to re-use them, only give the cards access to specific entry points at limited times.  If you can’t do that…you’re out of luck.

Keep a camera watching every entry point where someone may try to passively intercept or brute force your system.  Make sure that entry points are clear with no place to hide small receivers near card readers.

When buying cards, make sure you use as few bits as possible for any sort of facility code.  Ensure the card numbers are randomly distributed throughout the remaining bit space.  Never use cards with predictable or sequentially assigned numbers.  Don’t custom program your cards with employee ID or anything else that can be derived or learned from other sources.

Use a pin pad on as many readers as you can.

Hand out RF-shielding badge holders or sleeves to help users protect the access cards when they aren’t in your facility.

Have your security personnel specifically look for “new card readers” on the property.

Programmatically look in your logs for anomalies.  Shut down a reader and dispatch a guard if you get ten strikes in a row.  If nothing else, the reader may have broke and you’ll need someone there to direct traffic anyway.

Good luck.

 

30DEC — A note from the future!  HID iClass “Standard Security” has been publically broken.  See http://www.openpcd.org/HID_iClass_demystified for details.  Make sure you’re using your own keys in “High Security” mode.

h1

Mifare 1K cards in.

March 6, 2010

I just got my new S50 1K cards in today.  They come individually wrapped and ready to go.

Here you can see the chip in the corner of the card.

A random sampling of the cards read fine in the Omnikey 5321.  They appear to have a default KeyA and KeyB of 0xFFFFFFFFFFFF.  I’m going to have to tweak some python I’ve been using (RFIDIOt) so I can write the data I want to the cards.  Hopefully it will all work as planned!

h1

Cards side-by-side

March 2, 2010

HID Prox, HID iClass, Indala ESP

From left to right, the cards are:

  • HID Prox card, clamshell form-factor
  • HID iClass card, ISO form-factor
  • Indala ESP card, clamshell form-factor

Notice the thickness of each card.  Those Indala cards were like bricks!

h1

HID Omnikey customer service proves me wrong.

March 2, 2010

After a day of back-and-forth over the weekend, HID reps in the UK and Austria were able to assure me that the OSX drivers for the Omnikey 5321 are supposed to enable the RFID functions on the reader.  Based on their insistence, I started troubleshooting and discovered that pcscd in OSX is flaky.  It cannot handle USB reconnects or machine suspends.  If you are careful to kill pcscd before connecting the reader or waking from suspend every time, it restarts, loads the driver, and works correctly.

Although their site says that contactless cards are not supported by the OSX driver, the latest one does in fact work the same as the Linux driver with the cards I have at my disposal.  Like the Linux driver, it still does not react to EMV tokens.  I can verify that it senses and IDs iClass cards just fine.

A sincere thank-you to Markus and Mike from HID, especially to Mike for getting back to me on a Sunday.

h1

The Omnikey 5321 USB

February 28, 2010

It’s been a fun time setting up my brand-new Omnikey 5321 USB smartcard/RFID reader.  I worked with one a year or so ago, and was duly impressed.  This new one is just as solid.  HID makes quality equipment, and has acquired companies that make quality equipment.

HID provides drivers for use under Windows, Linux, and Mac OS X.  The completeness of those drivers decreases in that order.  I acquired this reader to work with contactless smartcards, including Mifare and iClass cards.  The cards I have to test with at the moment are an ISO14443b card and an EMV (PayPass) token.  All of these operate on the 13.56Mhz ‘standard’ RFID frequency, but are not all equal in the eyes of the 5321.

I first borrowed a Windows laptop to make sure the reader worked.  HID provides a driver and a test application for Windows that I am familiar with.  Once it was set up and the USB driver changed to the HID factory driver, I tested the cards.  The 14443b card came up with the right Card ID and ATR.  The EMV token was detected as an ISO14443b device.  The Card ID and ATR looked right.  All is good on the Windows front.  Unfortunately, I don’t have a Windows machine of my own to do development on.  In each case, bringing the card near the reader resulted in the activity light flashing as the card was read.

My next adventure was to try out the OSX driver bundle.  Mac OS X uses pcscd to talk to smartcard readers.  HID provides a CCID-style driver bundle, currently version 1.0.0 released March 2009.  It loaded up fine, and detected the reader.  As promised by HID on their specifications page, the OSX driver does not work with contactless cards.  In fact, the reader does not respond at all when cards are brought near it … the activity light does not flash.

Finally, I loaded up the Linux driver bundle, version 2.7.0 from February 2010.  I was fortunate to have read up on installing pcsc-lite ahead of time, which kept me out of trouble by instructing me to configure with –enable-libusb and –disable-libhal.  After installing the driver and loading up pcscd, the reader was correctly identified.  The 14443b card was read without any problem.  The Card ID and ATR were both as expected.  However, the EMV token was not read at all.  Just like with the OSX driver, the activity light didn’t flash when it was brought near.

It’s clear that the Windows drivers allow the reader to use all of its capabilities.  The Linux driver fails to read at least one type of RFID token.  The HID-provided OSX driver is nearly useless — the stock PCSC-Lite CCID drivers provide the same functionality in the 5×21 series of readers.

I’m hoping that the Linux drivers will work with the Mifare and iClass cards that are on their way.  If not, I’m going to have to get a Windows machine working.  That would be a shame.

h1

Proximity Card Answers

February 26, 2010

What’s a “static proximity card”?

Proximity cards used in physical security applications generally work on low frequencies, and are energized by ‘proximity’ to a reader.  Upon being activated, a static proximity card will respond by modulating the signal to send out a sequence of bits.  Static cards have no handshake, no ‘smarts’, and will always spit out the same sequence of bits to anything that manages to energize them.  They are a single-purpose ID code transmitter.

What’s wrong with static cards?

Static cards will broadcast their ID anytime they are activated.  They cannot determine if the signal activating them is from a legitimate reader or not.  Conversely, static card readers cannot verify that the ID code they recive is from a legitimate card.  The ID code, once intercepted, can be used in place of the card to gain surreptitious access for the entire lifetime of the original card in the security system.  In addition to stealing ID codes from cards, an attacker can attempt to guess codes by using the readers in the system.  While static protocols claim between 44 and 128 bits for the ID codes, the differences between cards enrolled in the same security system can be as low as 16 bits.

Why pick on HID?

It’s not personal.  HID http://www.hidglobal.com is the single most common vendor of proximity card physical security systems I’ve come across.  There’s an industry of other manufacurers that make equipment compatible with the static “Prox” and “Prox II” protocols that HID created.

h1

Why Static Proximity Cards Are Dangerous

February 26, 2010

I’m setting up another HID Prox security demonstration.  I’ve cleaned up my equipment so it doesn’t look quite so hacked-together.  I’m working on some long-range antennas and the code to safely support them.  Once it is all working, I hope to be able to…

  • Sniff cards being read across the room by a legitimate reader
  • Flash a room and read card responses
  • Brute-force desired bits on a proximity card

Already I can read a card to capture its number at short-range with a variety of readers.  With the card’s number, I can easily retransmit to a reader.  Basically, the existing system I’ve assembled lets me read your card and use it later at my leisure.