Subscriber Discussion

Does The Use Of A Multi-Class-Type Credential / Reader Create A Long-Term Security Issue?

UE
Undisclosed End User #1
Feb 06, 2017

Let’s say we dealing with a large legacy electronic access control implementation that one wants to move to newer, more secure technology.  The implementation of "multi-class" / multiple technology credentials and/or readers is common to facilitate the change over time.  Assume the legacy is 125 kHz cards/readers with ye ol' 26-bit Wiegand.  Assume hundreds of credentials are already assigned and hundreds of 125KHz-only readers deployed.   Forklifts aren't possible due to time and money but we need to start moving in a better direction ASAP.  Card skimming/spoofing is not very difficult with the older tech.  Yes, it also plausible for some of the newer stuff out there but due to it being more difficult it’s arguably a decreased risk. So even though one might be rolling newer technologies with higher-security features (encryption), it seems that as long as that newer stuff is multi-tech capable that someone could always still exploit the older "side" if the multi-tech card to use with the older "side" of the multi-tech reader.  Only when all readers or credentials are the newer selected (as secure as it gets) technology and ONLY that technology instead of a multi-tech concept do you alleviate the baggage of the security gap.   Am I missing something with this line of thinking?

(1)
Avatar
Mark Jones
Feb 06, 2017

Given the scenario you describe, no you are not missing the point.  If you employ a legacy card and it is "spoofed" as you call it, the fraudulent card would be read by the multiclass reader.  It will read what is put in front of it.  The security of a multiclass (SEOS in particular) is that there is an extra layer of encryption between the new card and reader that is unique to the site/owner.  The advantage of Multiclass is the ability to accommodate multiple formats (including legacy).  From the owners perspective, forklifting is not necessary because you can replace the old readers as time and budgets allow and keep your credentials in place until you are able to hand your users new cards.  Two of the most limiting issues to replacing large card access systems it the migration of the entire user database to a new operating software and distribution of the new media.  Multiclass helps to eliminate the new media portion.

Avatar
Brian Rhodes
Feb 06, 2017
IPVMU Certified

So even though one might be rolling newer technologies with higher-security features (encryption), it seems that as long as that newer stuff is multi-tech capable that someone could always still exploit the older "side" if the multi-tech card to use with the older "side" of the multi-tech reader.

This is true, and emphasizes the importance of changing user credentials in order to 'improve' security. Makes no sense to upgrade multi-tech readers but then let less secure low-frequency RF cards remain in service for years.

Only when all readers or credentials are the newer selected (as secure as it gets) technology and ONLY that technology instead of a multi-tech concept do you alleviate the baggage of the security gap.

100% agree

UE
Undisclosed End User #1
Feb 06, 2017

It seems it would also make sense to disable the 125 KHz "side" on the multiclass-style readers once all your credentials are upgraded.  I assume this is doable with config cards on most products but I have not looked into that.   I think this concept is less of a risk but it could help protect against a brute force (incrementing replay) just spewing out card numbers.   It wouldn't be the 100's or more per second kind of stuff we see in ITSec but it's still doable and fairly quick if the facility code is known.  

Again, I think this is rare and I worry about other things much much more but seems like that would just be good follow through.  It would also flush out any old junk credentials that might be lurking.  They shouldn't exist... and should at least be removed from the system but it just depends on the organization how tightly that is controlled. 

Some organization would catch something like that, the brute force attempt that is, very quickly; Some would never know. This is an area where many EAC software packages could add more features to help catch this without requiring as much human attention.  X failed tries in Y seconds event that can be used to trigger whatever someone wants via their rules system. 

Avatar
Brian Rhodes
Feb 06, 2017
IPVMU Certified

One key tactical step to employ with credential management is to use a different facility code and credential CSN scheme when upgrading cards/fobs/etc.

That way, system admins can disable entire (obsoleted) facility codes from being used in a system. Also, a different card CSN scheme, perhaps with 8 digits identifying users versus 4 or 5 digits common with 125 kHz cards, can doubly serve to 'weed out' potentially spoofable credential IDs in a system.

(1)
UE
Undisclosed End User #1
Feb 06, 2017

Wholeheartedly agreed.  We have one EAC system where we can do this easily (as most can) and another that cannot as there isn't a facility definition/card definition concept, each credential added to the person is just whatever it is.  Facility/card# combo representing the person. Pros and cons to each approach.  In some ways I like the latter.  None of that offset stuff to deal with overlap. (of course moving forward I want the overlap gone too.)   In other ways, like this maybe it's a loss but I can always find the ones I'm looking for, it'd just be more manual work to disable them. 

 I was thinking about the new facility code concept as I was working through the thread this morning and that spurred another thought.  Multi-class/Multi-Tech credentials could then reveal from their weak side that nice shiny new info you might not want leaked out.  It's a bit security by obscurity but it's all about layers and I'll take whatever I can get. If at all possible it'd be better to arrange the logistics of the migration so the newer cards are only the new tech. Sometimes possible, sometimes not but certainly something to consider. 

U
Undisclosed #2
Feb 06, 2017

I think the only thing you're missing is the general point and purpose of what you're describing in the first place. 

 

These are basically your options when you talk about migrating to a new card technology:

 

1. Forklift everything. Readers and credentials all new in one fell swoop. Big cost up front, and quick turnaround. Feasibility depends on total business size. TCO is equal to scenario 3 below, and is by far the most secure. 

 

2. Issue dual-technlogy cards (ie ye ole 26-bit prox + Indala), and gradually replace readers to the new Indala format (hypothetically. No one should ever do that [go to Indala] just for the record.). This allows people to continue accessing all locations across their business and start implementing the more secure technology. High cost for going to dual technology cards, and then the cost of replacing the readers. TCO is the highest in this scenario. 

3. Replace readers with multitech readers as funds are available.  Once all readers have been replaced, forklift cards to the new technology. Deactivate old technology on readers. Cost is stretched out over whatever timeframe is necessary to replace readers. TCO is equal to scenario one, but security is lessened while the readers are being replaced. 

 

Bottom line, the purpose of a multitech reader isn't to immediately make a system more secure. The purpose is to give yourself a reasonable upgrade path to a more secure technology. 

These days, anyone selling prox should be kicked in the face.  Just no excuse for it.  

(2)
(1)
Avatar
Brian Rhodes
Feb 06, 2017
IPVMU Certified

These days, anyone selling prox should be kicked in the face. Just no excuse for it.

lol.  You'd better pack your lunch.  (32% still prefer 125 kHz)

 

U
Undisclosed #2
Feb 06, 2017

Oh, I'm well aware. Just like there are tons of "integrators" who will still propose analog just because.

That doesn't mean it's the right thing to do, or that it's justifiable.

Anyone that says they "prefer" it is really just covering up for the fact that they don't know what in the hell they're doing.

RK
Rashid Khan
Feb 08, 2017

If there was a way to hack / find a card credential, how can this credential / token be used to allow a controller to open a door without the card being registered / added into the system??

Avatar
Scott Lindley
Feb 10, 2017
Farpointe Data, Inc.

Wonderful Friday topic!

Agreed Integrator #1, it would seem to make sense to disable the legacy side of the multiclass-style reader once all the original access credentials have been upgraded.   However, if the legacy technology can be disabled with a config card, then most likely it can also be re-enabled with another config card.  This may indeed create an unrecognized, but very real, vulnerability.

Here's another real challenge with today's sophisticated 13.56MHz credentials: what identifier to use for access control? Many end users will select to have access decisions made based simply upon the credential’s CSN (card serial number), and not the more secure method of basing access decisions upon the identifier data protected in the credential's encrypted memory.  Why?  The CSN is available on (nearly) all contactless smart cards.  They are regulated by ISO (international standards organization), with typical lengths of 32-, 48-, 56- or 64-bits.  And they can be sourced from a multitude of low cost providers (See here: www.ebay.com/itm/like/262442622111?lpid=82&chn=ps&ul_noapp=true), eliminating the concern of being locked into a manufacturer's proprietary technology with secret key, a system's custom format, or an integrator's extra layer of encryption.  However, the problem is that the CSN, because it is open, standardized and unencrypted, is an easy target for hackers and other bad actors.  Technology exists allowing CSN's to be cloned and modified in unauthorized manners.

And Integrator #2, if security is the goal, then I agree with your first option of forklifting the entire system in one fell swoop.  This is the most secure method.  And building on Brian's comments, personally I've seen success for end users when integrator's clarify the built-in encryption features of these 13.56 MHz cards. Many end user customers have heard that the 13.56MHz contactless smart cards are more secure than 125kHz proximity credentials, but they simply don't appreciate the finer differences. The integrator that fully elucidates the credential’s benefits certainly increases the opportunity for their end users to obtain the maximum return from their credential investment.

New discussion

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

Newest discussions