The Prox Reader Shootout - Allegion, AWID, Fairpointe, HID, Honeywell, Rosslare

Command Corporation • IPVMU Certified

We use the proxpoint reader more than any other reader. They’re rock solid and for the price, they’re well worth it. Our problem right now is finding a low cost $50-$150 keypad/reader. I have had a lot of requests for something like the following…”we want a keypad code that is only good for one day during business hours to provide to students who are only coming in for one day and credentials for teachers and employees. This way we’re not handing out dozens of credentials everyday.” Most of these customers are small educational or daycare type facilities with small budgets.

Reactions:

(1)

Brian Rhodes

IPVMU Certified

In reply to John Bazyk

That's interesting, I can see why they would want such a thing too. 'Expiring PINs' for a really low-cost credential.

Which keypad combo have you recommended in the past? HID's ProxPro 5355 with keypad sells for ~$200, and they go up from there.

Reactions:

Jonathan Lawry

•Sep 06, 2015

Trecerdo, LLC

In reply to John Bazyk

What does an "Expiring PIN" have to do with credentials at all? This is a controller/software function. If you have any reader with a keypad, you can do this with the right software/controller.

Reactions:

James Morrice

a detail for you, did you know that the HID6005 have a lifetime warranty? it certainly helps if your installation has a number of external readers.

Reactions:

(1)

Undisclosed #1

IPVMU Certified

Generic is really the brand name?

Who was the marketing whiz that came up with that one?

"Beware of cheap imitations, remember to look for the capital G!"

Reactions:

(1)

(2)

Brian Rhodes

In reply to Undisclosed #1

IPVMU Certified

'Generic' is not the original manufacturer's name, but it is resold under the 'Generic' name at Amazon. There are almost a hundred access products lumped into that name:

The manufacturer is undoubtedly a contract manufacturer, but they are generic reference designs.

Reactions:

(1)

Undisclosed #1

IPVMU Certified

Thanks, didn't get that at first.

So the vendor chooses to list the manufacturer as Generic on Amazon, instead of "XYZ Readers", because people trust Generic?

Reactions:

(1)

Undisclosed Integrator #2

I'm confused - how would a prox (125 kHz) reader read a DESfire (13.56 MHz) card? How would HID prevent non-HID prox readers from working with their prox cards? Unless you mean FlexSecur (it wasn't mentioned)?

Reactions:

Brian Rhodes

IPVMU Certified

[Note: The Aptiq PR-10 does not read the full 13.56 MHz DESFire card, but it reads the CSN in MIFARE cards. For full compatibility with 13.56 MHz formats, the Aptiq MT series of reader is needed. I clarified this in the report above.]

That particular reader, the Aptiq PR-10 can read credentials at both frequencies. Not HID iClass, but DESFire Classic.

If a reader does not have the proper key to 'read' HID Prox, it just doesn't transmit any info. You present the card, but nothing is read.

Reactions:

Brian Rhodes

IPVMU Certified

Also 'FlexSecur' is essentially the Indala version of facility codes. It would not guarantee interoperability either, unless I fundamentally misunderstand it.

Reactions:

Undisclosed Integrator #2

I can't find anywhere that they advertise the PR-10 as supporting 13.56 kHz credentials. That's certainly interesting to know, though.

FlexSecur is what it sounds like you're describing: mutual auth between the reader and the card.

https://www.hidglobal.com/sites/hidglobal.com/files/indala-flexsecur-wp-en.pdf

http://web.mit.edu/keithw/Public/MIT-Card-Vulnerabilities-March31.pdf

I guess I've never seen a standard HID Prox card that couldn't be read by any old reader. My understanding of the process from playing with proxmark3 was that standard prox cards do nothing more than transmit their card data when powered by a reader. Do you have any technical reading on the process that details how HID cards/readers differ?

Reactions:

Brian Rhodes

IPVMU Certified

I believe the format of the bit structure, ie: H10301 is the important part. If you want your 125 kHz RFID chip to be read successfully by an HID formated reader, the information has to follow that bit format.

As far as enforcement or the difficulty in non-HID partners making HID compatible readers without liscense, it didn't happen in the readers we tested.

Note: We did not test 'non-HID' cards that claimed HID 125 kHz compatability. We tested 125 kHz EM cards, and HID Prox II cards, but I suppose non-HID H10301 cards can be easily purchased. (Like keyblanks that fit a Kwikset lock, but aren't Kwikset brand blanks.)

Reactions:

Undisclosed Integrator #2

Readers don't know anything about card formats, though. They just pass binary data on to the access control panel (via Wiegand), which is what does the decoding of the data into a card # and determines, based on that, whether or not the door should be unlocked.

I'd be extremely interested to know how HID would prevent their 125 kHz cards from being read by any standard 125 kHz reader. It would have to be some different kind of physical signalling method, no? If they used FSK/Manchester like everyone else, you'd still be able to at least get static binary data from the card that could be used to identify it even if it didn't decode to match the # printed on it.

Reactions:

Brian Rhodes

IPVMU Certified

Readers don't know anything about card formats, though.

This isn't true. They may be able to energize a card to enact a read, but if the data comes back improperly formatted, it just is ignored. (no beep)

Also key-swapping is a primary improvement of iClass vs. Prox.

If they used FSK/Manchester like everyone else, you'd still be able to at least get static binary data from the card that could be used to identify it even if it didn't decode to match the # printed on it.

This makes a lot of sense, and I believe it is the basis for CSN swapping in the ISO 14443A&B formats. As far as the mechanics in our tested readers, (and we tested a good selection of readers in the market) the HID readers couldn't (or didn't) read EM/Generic cards and vice versa. Like I mentioned before, I believe the bit format (H10301) is the key variable here, because otherwise everything was 26 bit across the board. (all cards, readers, etc)

Reactions:

Undisclosed Integrator #2

•Aug 28, 2015

This helped to shed some light: http://www.proxclone.com/pdfs/HID_format_example.pdf

"Tag transmits the preamble and all 44 bits, but commercial RFID receivers only output Wiegand data for the last 26-37 bits (dependent on card format)."

So, there's more going on than just a stupid "contactless to wiegand" translation. Do you know if there's something in that metadata that HID legally prevents other companies from working with? That seems almost absurd to me, but then again... 09 F9 happened.

Reactions:

(1)

Robb Larsen

•Sep 03, 2015

Here is some info I found from HID when looking around for custom FOBs and trying to understand the technology Understanding Card Data Formats. Here is some EM information I found EM4200 Datasheet. (I have more datasheets, but this gives a good overview).

If anyone has some knowledge here, I could use some help. Looking for some custom printed FOBs. Found a style I like, but unsure if it will work with a standard HID prox reader. Formats available are:

H4102 (125 KHz, 64 bit, R/O)

H4200 (125 KHz, 64 bit, R/O)

Temic e5557/6 (125 KHz, 256 bit, R/W)

I-Code (13.56 MHz, 512 bit, R/W, ISO 15693 & ISO/IEC 15693)

I called HID asking about this and they stated the reader didn't care, but if it's not a standard format, then the bit parity would need to be manually entered into the access control software. The software/manufacturer I use allows has this custom "integration" if you want to call it that, but I'd much rather find something standard that works out of the box (and with our company's name on it). This is the only company I've been able to find so far, but no U.S. contacts Pascard Custom FOBs

Anyways hope the info was helpful and if anyone has thoughts on my dilemma I would appreciate any input. Thanks

Reactions:

Undisclosed Integrator #2

•Sep 03, 2015

In reply to Robb Larsen

"they stated the reader didn't care, but if it's not a standard format, then the bit parity would need to be manually entered into the access control software"

See, this is exactly why I'm confused.

Reactions:

Robb Larsen

•Sep 04, 2015

Ok think of it this way:

-The card/FOB is programmed with a certain bit parity or set of 0's and 1's (01100111011...that type of thing).

-The build of the bit parity is what creates the card formats (26-bit, 33, 35, 37, 40....)

-When you swipe a card by that reader, the reader just interprets the hexidecimal or the 0's and 1's and blasts that data back to the access control software/panel in the full string of 0's and 1's (again, 01100111011...)

-The access control software receives that string of 0's and 1's or bit parity and interprets the data through microprocesses built into its programming/database and after recognition, shows a site code and card number in your events page.

-If it understands the bit sequence (like 26-bit) it interprets all the 0's and 1's, then recreates the site code and card number from the sequence.

-If you've ever dealt with a "Card format not recognized" in your access control system, its usually because someone is using another card that utilizes a different bit parity and your system cannot interpret the 0's and 1's (Though most systems can recognize several).

Basically, the proximity reader does just that, it reads the series of 0's and 1's that make up the card data. It's dumb, it doesn't interpret, it just reads and pushes the information back to the panel. The panel is what can understand the 0's and 1's string then know from that string what the bit parity, and subsequently, the card number is. (Disclaimer: I may be wrong or not providing full detail, but I think I'm about on).

The problem I have is that unless it's a standardized bit parity, breaking down that information to get the access control system to interpret it correctly is pretty difficult. Even with some of the programs out there that try to calculate the card style like the Brivo Card Calculator, it's still kind of a guessing game. Thats why companies like Keyscan and their K-Secure (37-bit Mifare I think) are secretive with this bit parity info (I asked, the tech support guy laughed......understandibly so, but hey, I took a shot). It's harder to replicate and in a way kind of forces you to use only their cards.

Reactions:

Undisclosed Integrator #2

•Sep 04, 2015

In reply to Robb Larsen

No, I get all that. "It's dumb, it doesn't interpret, it just reads and pushes the information back to the panel" is apparently not true, from the other discussion going on here. But then HID seems to support that idea? That's why I'm confused.

I don't think that "bit parity" is the proper term, by the way. There's such thing as parity bits, but what you're describing is typically referred to as the card/badge/credential format, in my experience.

As far as reverse-engineering badge formats goes, it's actually quite simple if you have a system that will give you the raw hex or binary from the card reader, and either the card # printed on the back or a system that will show you the card number. Even if you can't get the exact format, the binary transmitted by the reader to the panel will never change, so you could just define the entire bit stream as "card number".

IPVM lackeys - is there a post on that?

Reactions:

Brian Rhodes

•Sep 04, 2015

IPVMU Certified

So I've been reading and asking questions on this myself, but we do not have a post on it nor do I expect us to write one because it is really deep 'in the weeds' that goes beyond what 99% of designers need/want to know.

However, with that said, I think you correctly identified the right answer in looking at the modulation format. You wrote:

"Come to find out Indala uses PSK and EM4102-based devices use ASK. Still, I'd love to know what HID does differently that would prevent their cards from working with "unlicensed" readers."

I was surprised to learn there are actually three types of modulation: ASK, PSK, and FSK.

You mentioned two of the common ones, ASK and PSK. It turns out HID 125 kHz uses FSK:

The 'reciever' at the reader has to be more sensitive than ASK or PSK to detect the subtle frequency shifts between a '0' and a '1' with FSK. This is part of why the HID models cost more; they are built with more exacting/sensitive 'recievers' in the reader.

'Generic' EM cards likely use ASK, like the 4102, 4002, and 4001 formats.

In other words:

HID card to non HID reader: no read, because reader doesn't use FSK.
non HID card to HID reader: no read, because card doesn't use FSK and HID reader ignores anything else

For HID readers, they just turn off the ability to read non-FSK cards. For non HID readers, they likely aren't built with advanced FSK chips, nor would they ever need it since you're buying generic cards anyway.

So Und2 is right, there is nothing encoded in the card at all. The reader (especially cheap ones) may not work with all modulations. It's nothing more than 'security through obscurity'.

Reactions:

(1)

Undisclosed #1

•Sep 06, 2015

IPVMU Certified

For HID readers, they just turn off the ability to read non-FSK cards.

Is it up to the end-user to turn it off in some models?

Reactions:

Undisclosed Integrator #2

Come to find out Indala uses PSK and EM4102-based devices use ASK. Still, I'd love to know what HID does differently that would prevent their cards from working with "unlicensed" readers. Even FlexSecur is mostly based on technology on the reader itself rather than on the card.

Reactions:

Brian Rhodes

•Aug 28, 2015

IPVMU Certified