Subscriber Discussion

Microsoft Phones Are Unlocking HID Readers

UI
Undisclosed Integrator #1
Feb 21, 2017

Microsoft Lumia 900 series phones are able to unlock doors via HID iClass Omniclass readers by simply locking and unlocking the phone several times in front of the reader (Honeywell NetAxs controllers with WinPak).

(4)
Avatar
Brian Rhodes
Feb 21, 2017
IPVMU Certified

Yikes, is this something you've seen firsthand?

Are any special apps being used?

UI
Undisclosed Integrator #1
Feb 21, 2017

Seen firsthand, no apps in use! Note the reader & controller in "default" multiformat state (all formats like 24 bit Wiegand etc allowed).

(2)
UI
Undisclosed Integrator #1
Feb 21, 2017

Is there anyone else facing the same or can anyone test this out?

DD
Daniel Dollinger
Feb 21, 2017

NFC on phones and iClass are the same radio frequency, 13.56MHz.  When an iClass card is encoded (most integrators buy them pre-encoded), it is done with a NFC encoder chip, which is the NFC technology as in your phone. 

What does the event log show? It should be a matching card number.  WinPak by default (at least older versions) ignores facility codes, and only uses the card #.  This behaves like this until the facility code is entered in the programming.  We had a customer who recently had a tenant install an access control panel in their suite.  Whereas the customer ran WinPak for years without problems, the day the tenant's system was finished, the tenant had access into the entire building beyond  their suite.  As it turns out, the original WinPak system did not have the facility code entered, and the card numbers from the tenant were in the same number range (1 - 100) as the older WinPak system.  Adding the facility code resolved the problem.

 

(2)
UI
Undisclosed Integrator #1
Feb 21, 2017

Hi Daniel,

Thank you for your reply.

Very informative. I can verify that disabling all card formats except 34 Bit Wiegand & applying a site code (facility code) does stop this from happening.

But there is one thing that i dont understand, simply having an NFC enabled phone in front of the reader shouldnt create a card no or token which gets accepted by the controller, there is no special app etc running on these phones, simply locking & unlocking several times does the trick, so where is the system getting the card number and that too a match to open the door?

 

Avatar
Ethan Ace
Feb 21, 2017

It's bizarre that it's matching a number and opening the door, but I've seen phones respond to card readers before.

For example, if I hold my iPhone 6 up to multiclass readers at the office, it wakes up the phone and opens up Apple Pay on the lock screen. If I actually put my thumb on the fingerprint reader (on the phone), it will send a card number to the reader. I haven't ever investigated what number it's getting, though. I just thought it was a weird little coincidence. 

(2)
DD
Daniel Dollinger
Feb 22, 2017

 

Keep in mind the iClass readers are very "dumb" as they are read-only and meant to do only 1 thing.  The phone is actually trying to communicate back and forth though, so its possible the phone NFC software might be trying several things to read it as its job is to interface with a lot of equipment... not sure if anyone other than a phone NFC programmer would have a true answer.

(1)
(1)
UI
Undisclosed Integrator #1
Feb 21, 2017

Perhaps if IPVM can be so kind as to perform this test and if it is indeed the case then that is a big loophole that needs covered by Honeywell & HID!

U
Undisclosed #2
Feb 21, 2017

Perhaps a bug is within the NFC technology scope and not the application scope. Someone please let me know when I can charged up my Starbucks card.

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions