Contactless Access Credentials Guide

By Brian Rhodes, Published Oct 29, 2018, 11:45am EDT

Contactless credentials are the most common component used in an access control system and while many look alike externally, important differences exist.

Choosing the correct one can be the difference between a secure facility and wasting significant money. Understanding how they operate and what their specifications mean is a big challenge.

** **** ******, ** cover *** ***** ******** needed ** ******* *** right *********** *********** ***** time, *********:

  • *** **. *** ********** Formats
  • *** *** **. **.** MHz ***********
  • ******** *****
  • ******** *****
  • **** **/****** *******
  • *** ****** **. ******
  • **** *******

Credentials ********

***** ***** ********** ******* exist, *** **** ****** choice ** **** '***********' types. ****** **% ** systems *** *********** ***** or **** ***** ** unpowered ******* **** *** excited *** **** **** brought ***** ** * reader ****. **** '******** power' ******* ** ************** ****** ********. *** ******* ** demonstrated *************** ** ************ *********:

** ***** *** ******* principle ** **** ** our ********* ******* ********, ******* *** ****** itself ***** * ***** collected ** *** ****, eventually ******** ****** ** a ****** **** *********** powers * ******** **** transfer ******* *** ***. The ***** ***** ******* typical ******** ********** ** the ****, ***** *** wire ******* ******** ******, the ********* ****** **, and **** **** ********** ICC **** (**********) **** back ******* *** ******* to *** ******:

** *******, *** *********** credentials **** **** *** but *** ***** ********** like ********* *********, **** of ********** ****, **********, and ****** ** *** data ******* **** ** the *****. ** *** sections **** ******, ** examine ***** ********** ** depth.

Contactless *********** ********* ** ******

*** ** *** ******* differences ** *********** *********** is *** ****** ** the **** ** ********, typically ********** ** *** manufacturer. ******* ** *****-******** of *********** *********** *** ******* ********* ** ******** ** *** ****** *** *** *************.

*** ********

***** *** ****** ***** migrating **** **** '*********' credentials ** *** ***** 1990's, HID ****** ****** *********** **** its *** *** "****" *********. *** **** of **** *****, *** *** ****** the **** ****** ******** market ********** ********, *** OEM ** ******** *** access ****** ********* *****, Honeywell, *** *******. *** company's ****-***** ******* *******:

  • "*********": ** ***** *** *** ******, *** ***** ********* used *** ********* **** in *** *******
  • ******: ** *** ****** specific **.** *** '*********'

*** ** *** **** common ****** *** *********** in *** **. ******* of ********** ****** *****, HID ** **** ** license *** *** ** its ********** ******* ** a ******* ** ********** and ****** *************. **** when ********* ******* '*** 14443 *********' *********, *** strictly ******* "**** *" standards (** **** "*" - ********* ** **** detail *****).

*** ********

******** ******** *************, ******-***** *** ****** a ****** ** '***********' credential ********** **** ** a ****** ** ******* - ********, *******, *** industrial. **** ********** ******** of *** ********* ** credential **************, *** ****** a ******* ** ***** built ** ****, *********:

  • ****** ****: ***'* *** *** ****** ***** ** ***** drafts ** *** *********, but *** ** ****** adopted ** ***'* "*********" lines
  • ******/*******: ** *** *********-***** NXP '*********' ******, **** operating ** **.** *** The '*******' ******* *** introduced ** *** ***** 2000s ** *********** *** format **** '****** *******' credentials. ******* *********** ******* stronger ********** **** ******** higher ********** *****. *** 'Classic' ****** **** ***** scrutiny *** ***** ********** ** snoop *******, *** ******* countered **** ******. ******* these ************ **** **** only ** ***********, *** existing ****** ******* ***** still ** ****, *** new ****** ****** ***** as '******/*******'.

****** ***, ***'* ********** formats *** '*******-****' *** the ********* ********* *** available *** ********** *** for ** ****. *** manufacturers *** *** ***** product ** "**** *" standards. ***'* *********** ** largest ******* *** **, mostly ********** ** *** early (******** ** ~****'*) adoption ** *** ****** formats ****** *** **, but *** *****'* ******* are ***** *** ******* ones **** ** ****** and **** *** ******** access *******.

US ** *** *****

******* ** *** **************'* strength ** **** *** the **** ** *********, MIFARE, *******, *** *** associated *********** *** ******* outside *** **.

*******, *** ******'* ********* markets *** ** *** Americas, ********** ** *** US. ******* *** ********** cost ** ********* ********* credentials *** *******, *** ******* also ******** ******** **** use *** ********** *** formats and *** ***** ** greater *********** ** * result.

125 *** ** **.** ***

*** **********'* ** ********* factors * *** **** in *** ***********. ******* readers *** **** **** credentials ********* ** ******** matching ***********, **** ********* is *** ***** ** consider. ** ** ******* in *** **** ****** ********, ** ********* *** format ** *** *****, credentials *** ****** *** read. *** ***** ***** shows *** ********* ** popular *******:

******* *** ******* ********** between *** *** *** 13.56 *** *********** ** credential ********. ** ** addressed ** ******* **. ****** ****, *** *** ******* do *** ******* ********** and *** ****** ******* or *******. *******, **.** MHz ******* *** ********* (usually *** *** *** or *******) *** ********** data *** **** ** read ** * ****** that ** ************ ***** *** key ** ** **.

Deciphering ********** *****

*** ** *** **** challenging **** *** *********** and *** ***** ***** is ****** *********** ***** credential * ****** ** using. *** ****** ** crowded **** ******** ** options **** ** ********** of ************* *** ***** that *** ****** ** be * ***** ***** card. *** ***** ***** details **** ********* ********** types **** ************ ********* performance *** ******** ***************, yet **** *** **** the **** ** *** untrained ***:

*** *********** *****, *** must **** ***** ********** that *** *** ********* clearly ******* ** ******* labeled ** *** **********:

  • ****** ****: **** ********** *** *** how **** **** *** credential *********, ******* ******* by ** *** ******** for ******* *******. *** example ****** ** *** typical ** *** ******, H10304 ** ***'* ******* 37 ***, *** ** on. *** **** *** to ******* *** ****** used ** * **** is ** ****** * box ***** ** ******** cards (*** ***** ***** 'Card ****** *******'), ** use ** ****** ********** (*****'* ******* ******) ** interpret *** *** *********** output ** * ******** format. ** **** ***** are *** *********, *********** the ********** **** **** by ******** *** ****** used ** *** ****** ******* ********** ******** application, ********* ** *** cardholder *** ****** ************* settings.
  • ******** ****: **** ********* ** NOT ******* ** *** card ** **** *****. This ***** ** *********** is **** ********* ***** on *** ****** *** can ** ******* ***** the **** ****** *********** for ****** ****. ** certain *****, ****** ******* must ** ********** ** accept ******** ******** ***** and **** ***-*** ******* may ***** ********** ***** to *** ******** ******. Without ******* **** ****, credentials *** *** **** to ****.
  • **** **/****** ****** (***/***): ** **** *****, the ** ****** ** embossed ** ******* ** the ****. **** ****** is *** '****** **' that **** * **** to * ******** *****. While ********** ******* *** not ** *****, ********* numbers ***, *** *** same **** ** *** Facility ***** ********** ****** be ****** ***** ** the **** ******. *** image ***** ***** 

*************, *** ***** *****/***** Number *********** ******* ** the **** ** ***** not **** ** *** access ****** ** *** and ** **** ******* to ****** ** *********** the ****** ** *** card ** ******* ** a ******** ***********, *** user, ** ******.

** **** *****, * card ****** ** *********** will '****' ** ******* card *** * ***, but **** ****** ***** may **** ******* ******** days.

*****, *** *** *** cards currently ** ********** ** often *** ********, ******* way ** ****** *** three ****** ** **** information, ** *** * reordering **** ******, ** shown *****:

The ***/*** ***** ********

**** ****** ********* ***'* ****** **** ***'* ****** *********, and ** *** *** ambiguous ************** ** ** ISO ********, **** ***** 'look' *** **** ** most *******. *******, ******* early ******** ** *** standard **** **** *** differentiation, *** *** *** designed ***** '*********' ********* with * ********* ********** structure.

*** *** ****** ** both ******** ** ********** claim '*** ***** **********', *** *** *** entirely ***************. ** ********* this **********, *** ******* 14443 ** ******* ***** '* ***/** *' ** ********* the *** *********. *** default, ***** ****** ****** of ***** ** ******** in **** * & B *****, *** *** encoded **** ** *** card ** ********** ******* the *** ******* *** original ******** **** **** for ************** *********.

** *******, ******* ***** is ** ********* **** in ***** '**** *' standards, **** ***-****, ***-** target ******, *** *** reader ******** ***** ****. However, ******* ******** ************ in *** ** ** from ******* **** * broader ****** ****** ******* use '**** *' ********** common ** ***.

*** *******, **** **** reader ******** *****-*, *** not *****-*, ******* ** practical ***** ** **** not ******* ***'* **.** MHz ****** *******, *** does ******* ***'* **.** MHz ******/******* *******:

** ********, *** ****** readers ******* **** '*' and '*' ***** **** the ***-*** ******** '***' such **** ****** **** of *********** **** **** with ***** *******:

13.56 *** ********* ****************

***** *** '**** * & *' ******** ** ISO ***** ********* ******* from ***** *** ****, it **** *** ****** mean **** *** ******** with **** *****. ******** of *** ***** *** the **** ** **** parts, ********* *** '**** Serial ******'. *** **** access *******, **** ** the ****** ****** **** identifies ****** *****, *** because **** ****** ** not *******, ** **** register ** '*** ********' readers:

  • ***/*** ******: *********** *** ****'* ****** identifier ** ******** ******* it ** *** ****** in *** **** '*********' media. **** ****** *** platforms *** **** **** number ** ****** * user, *** ******* *** the ******** ******** ** assign ******, *********, *** privileges.
  • ******* ****/*****: *******, *** **** ******** of ******* ****** *** card ** ********* *** unreadable ****** ********* ******* are ****. ********** *** access ******* ***** *** credential ****** *** ******* (**: *****, ***** *******) and *** *****-****** ************** (**: **********) **** ******** deployments, *** ****** *** is *** **********.

The *** ********

** ***** ** ********, not *** ********** ******* are *********. *** '**** Serial ******' (******* ** ISO *********) *** **.** MHz ***** *** ***** be **** ********** ** underlying ******, ********** ******, or **********. *** *** may ** ****** ** a ****** ** ** the ******, *** *** full **** *** ** the ********** **** *** be *********.

*** ******* ******* **** only * *** ***** and * ******* ** fewer ***********, ***** *** CSN ** *** ******* ID ** ****** *** to *** **** ** enrollment ** ***** **** as ****** ***** *******. However, *** ****-******** ***** where ****** ******** ********** is ******** ** ******** or **** *********** *** used *** ******** ********** systems, ***** **** ** identify ****** *********** ** often *** ********. ******, the ****'* ********* **** is ******** *******.

Form ******

********** ****** *** *** just ******* ** ***** or ****. ** ** cover ** *** ****** ********** **** ****** Tutorial, *** **** *** method ** ******* * credential *** ******* ********, tokens, ****-***** *****, ** even *******.

*** **** ****** ** the ********** ***** ** an ********* ************* ** overall ********** *** ******* life. *** *******, ***** a ***** *** **** may ** ***** ** print ** ** ***** on *** **** **** a *******, ** *** easily ** **** ** broken ** * ***** environment. * *** ***, while ********** *** ******** a ******* **, ** designed ** ** ******* enough ** ********* *****, harsh *********** *********, *** even ********** ** *****.

*** ***** **** ****** choice ****** ** ******** by *** **** *** *** user's ***********, *** *********, all ***** ********** ***** have ******** **** ****** options ** ****.

System ******

** ***** ** ****** systems, ********** *********/******* ****** most ****** ******. ****** selection **** ******** *** credential ******, *** *** subsequent ****** ** **** must ***** **** **** choice. ** ***** ** 'Access ********** ********' *********, this ****** **** *** generally ******, ******* *** reader ****** ********** ********** communication. ** **** ** the ******** ** ********** with *** ******, *** credential ****** ** * marginal ******, *** **** specify ********** ***** ***** on ********* *** **** of ******** ****** **** technology **********.

*******, **** **** ******** is ****, ******* *** costly ******* **** ********* require *********** ** *********** or ****** *******. ******** from *** ****** ** the ***** *** **** thousands *** ******* *** users, ** ******* *** uncommon.

Comments (17)

What about the huge vulnerability brought on by manufacturers that build 100's/1000's of batches of cards that share the same facility code and then sequentially number them?

https://www.linkedin.com/pulse/major-physical-security-vulnerability-standard-bryan-buenaventura/

Just so I understand the point, are you saying that once the facility code and a valid badge number is known, guessing other potential valid combinations is not difficult?

Correct. Just add +1 to the card # and you'll be able to take on the identity of the next (lucky/unlucky) employee to walk into that badging office that afternoon, right behind the person that you swiped the initial data from.

That's an interesting scenario.  In your experience, do you see non-sequential card orders, or 'randomized' numbering being used?

 

It's never done that way (as in randomized), and it is completely wrong not to. A very BAD practice, and a 3-part problem:

#1- Most Access Control Systems have low maximum limits on the number of Facility Codes with the worst ones allowing only 1, and others only permitting up to 8. The higher the number of possible facility codes, the better.

#2- The End User experience. Why ask the badging admin to enter 2 data fields, when 1 is so much more convenient?

#3- Card Manufacturers have stockpiles of cards that are sequential, why ruin these beautifully numbered sets? (Boy would I love to shuffle them in a giant bin and issue them to my clients in any order they'd end up!)

I've been around long enough to remember the old insert Wiegand readers. They actually had little bits of wire embedded in the plastic card that the reader head read as either a 1 or a 0 as you pulled the card out of the slot.  With those cards, you could get them serialized with the external number (or sometimes called a hot stamp) and a non-serialized internal number that was randomly assigned.  Each card shipment came with a cross-reference sheet that you needed to use to program the cards into the system because there was no way to determine the internal number from the external number.  And let me tell you, that was a pain in the ass to program a large batch of cards! :-)  And don't lose that sheet!

A way better way to do this is use the multi layer approach like HIDs SEOS cards that require a trusted platform and can't just be cloned.

Certainly a problem with old-fashioned Wiegand Prox cards, but one that modern installations using encrypted formats such as Mifare DESfire and the newer incarnations of HID iClass don't have.

I'll ask for forgiveness in advance for any stupid questions as I am new to the access control hardware. My company specializes in PIDs products and my higher security customers that I visit to work on our systems use a 2 layer approach. Most use a  contactless card combined with biometric hand scanners or something similar.

Do any of you with more experience than I see the industry heading toward a multilayer approach, say card readers and facial rec. for example as a more common set up?

It's not a stupid question in the least - the 'multilayer approach' you ask about is typically called Multi-Factor Access Control Authentication.  That link is our guide.

In terms of a trend, multifactor authentication is indeed becoming more common. Especially as performance of individualy types of readers improve, it becomes less of a time penalty to ask users to enter multiple credentials - PINs, Cards, Biometrics, are the most common.

Hello Brian

I am very new to access control so all the details are very interesting based in Trinidad and Tobago so in general we would be behind the USA and Europe in widespread access control adoption.

I came across the Keri NXT-3R  reader  used by a large local integrator this states "Encrypted Data Between Reader and Card or Tag" looking at the card that our distributor offered  NXT-I "125 KHz excitation / 62.5 KHz return" so I guess this is an enhanced proximity card...Something interesting is also that the reader has " ability to read HID 125 KHz credentials"...

Regards

Jerome

Just wonder how would I recycle the cards. Many times, they are printed wrongly on the outer surface...

I think in many cases, misprints are trash, which is a waste for sure.

However, you might be able to reprint on card-sized labels and cover up the misprints.

You could also use "Sticky Back" cards. I have a few customers that use these. One because of the situation you describe or that have a lot of turnover and recycle the cards over and over. There are many brand of them. These typically will print the same quality image as the cards you are using.

IPVM Image

Clear introductions

Simple and clear introduction. Great!!

I'm new to Access Control, but from what I gathered, Part A is basically used outside of the US because of licensing and industry standards in the US. It seemed as if part A could be less secure than Part B, does that mean that part A credentials are easier to copy or manipulate than Part B? If so, than that would mean that the United States would have a higher level of security within its standards.

There is not a 'more secure' version between Part A or Part B. The difference is due to discrepancies in how the ISO standard was initially understood between early adopters.

Rather than (unfairly) invalidate one of the interpretations as non-compliant, the standards group decided to clarify between the two using the 'part' clarifiers.

In terms of security, NXP offers 256-bit encryption, while HID uses 128-bit, but even then there are no reports of HID SEOS formats being cracked.

Read this IPVM report for free.

This article is part of IPVM's 6,735 reports, 909 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now
Loading Related Reports