I’m curious what the security of these NFC lock systems looks like. (I’m talking about the commercial building systems mentioned like Brivo and Unifi, not home systems.)
In particular, I know unifi cards rotate keys. So you can’t simply clone them with a Flipper, and this also means third party cards don’t work. By default, this is true, but you can’t simply clone turn it off, as mentioned in the article.
Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.
The physical access industry is a complete, unmitigated clusterfuck.
Even if you have a system which is more secure than UID-only (i.e. not at all), e.g. using DESfire EV1/EV2 (and assuming they use it correctly) to have a non-trivially clonable access token, 99.9% still use what the industry calls "non-transparent readers" (simply because "transparent readers" were invented in like 2023), which is to say the actual card/NFC reader out in the insecure area has the DESfire master key in it and performs the challenge/response and only reports the decoded UID back to the access controller over some wires. Which is obviously completely insecure and open to all sorts of tampering. The physical access industry puts tamper contacts on the card readers for this reason.
The physical access industry is generally extremely tight-lipped about how their garbage actually works. Half the reason is that they know they're selling insecure garbage for a lot of money, the other half is that the industry genuinely believes not documenting stuff increases security. The third half is that having documented and open systems would mean their franchise/installer people would maybe not be able to take their fat cut in some cases.
> Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.
Broadly, yes, almost all NFC based access systems are insecure and pretty broken. They mostly operate via security via obscurity, and the fact that anyone serious about security that deploys these systems will put a huge amount of effort into identifying one of an actually secure systems. More likely they will pair the NFC element with multiple other secure elements, such as photo badges, big security humans that demand people keep their badges visible, and card + pin entry on all important access points.
A big part of the reason why these Apple Wallet systems have taken so long to appear is because Apple seems to refuse to integrate with any system that isn’t built using secure cryptography. Turns out there aren’t many systems out there that use strong cryptography, rather than cryptographic systems that have been broken for decades.
Actually getting information on how any particular system actually provides its “security” is extremely difficult. Mostly you have to figure it out by being familiar with the different systems out there, and different NFC systems. Then it’s possible to parse the marketing terms into actual technical specifications that might give a hint at how a system works. The only sure fire way to find out, is to buy parts of the system (such as access tokens or readers), and evaluate the hardware using various NFC and RFID hacking tools to figure what manner of awful design this particular system uses.
> A big part of the reason why these Apple Wallet systems have taken so long to appear is because Apple seems to refuse to integrate with any system that isn’t built using secure cryptography.
That's not the issue. Rather, there's an issue of what protocols existing access control systems support, what the iPhone can reasonably expose, and a need for integrating iPhone provisioning into every system, and for the last part, Apple likely hiding this behind some costly MFI certification program.
According to Ubiquiti, Apple Home Key integration strictly requires that the lock, reader and "processing unit" is a single combined device installed on the door. If your architectures splits that into two or three devices, then you'll be turned away at the door. There's numerous of these access key types, with different features and requirements.
Also, just being NFC doesn't automatically make it fit into the box of a smartphone wallet card. For example, take transit cards that use on-card balances to be able to board a bus in intermittent-connectivity areas.
Aliro is an access control standard launching this year which all major players seem on board with. This avoids the integration, certification and gatekeeping headaches.
> Broadly, yes, almost all NFC based access systems are insecure and pretty broken
To clarify, some NFC based systems just use the card ID, use ancient deprecated card types that have been broken for over two decades, or both. If the NXP NFC Reader app says your fob or card is MiFare Classic, then yeah it's in that category.
But higher security solutions also mean no card cloning, so pre-Aliro the vendor would have to go out of their way to get e.g. Apple integration and MFI certification.
> Broadly, yes, almost all NFC based access systems are insecure and pretty broken.
This is like saying "almost all TLS/SSL versions are insecure and pretty broken". Don't use the broken ones!
> A big part of the reason why these Apple Wallet systems have taken so long to appear is because Apple seems to refuse to integrate with any system that isn’t built using secure cryptography.
The reason Apple Pay actually took longer than Google's solutions is because Apple (presumably) co-developed the payment networks' tokenization solution, which was required to avoid the problem of every issuer having to individually integrate with Apple or issue a "proxy payments card", which significantly complicates the business side of things (which is what Google Pay originally did, when it was still called Google Wallet).
It's definitely an impressive solution, but cryptography had little to do with it. Apple Pay uses the exact same cryptography as Google Pay and any physical credit/debit card issued in the past few years (in the US; decades elsewhere). If it wouldn't, you wouldn't be able to use it on any existing terminals!
Don't believe it? Here's some "Apple-grade" security in action: https://practical_emv.gitlab.io/ – a vulnerability, unpatched for years, because Apple has to work with the same standards as everybody else, since even they don't have the power to make every merchant, transit agency, and fuel pump rip out their existing hardware (or even software update it).
> The reason Apple Pay actually took longer than Google's solutions is because Apple (presumably) co-developed the payment networks' tokenization solution,
Google Wallet launched with NFC-based mobile payments in 2011. Apple Pay launched in 2014. Neither solution is fully rolled out yet.
Apple's "co-development" was all pre-launch, but not sure how much of this was Apple helping vs. Apple demanding. During this time, Apple demanded secrecy so that only select bank employees would know what was being developed/that it was being made for Apple.
Slow uptake afterwards is a matter of not only every issuer needing to integrate, but also every payment terminal/network needing to be upgraded. Apple in turn likely held back release in a region until enough banks and payment processors had done the legwork.
These services are still rolling out - Google Pay added two more countries last week! Apple Pay came to Egypt last year. Samsung Pay came to Germany in 2020, Denmark, Finland and Norway in 2022 and Saudi Arabia in 2024. Doing anything with the financial sector anywhere is a bloody pain.
Sure, there's a long tail of banks/cards that don't support it yet, but I think it's fair to call Apple Pay and Google Pay massively deployed and successful solutions.
> every payment terminal/network needing to be upgraded.
Absolutely nothing needed to be upgraded in the payment terminals, or even the acquirers' systems. Tokenization involves only the network, the issuer, and the wallet provider (for POS/in-person payments).
To a POS terminal, an iPhone looks indistinguishable from a regular old contactless card, unless it's explicitly looking at some of the new (and backwards-compatible) tags indicating otherwise.
> Sure, there's a long tail of banks/cards that don't support it yet, but I think it's fair to call Apple Pay and Google Pay massively deployed and successful solutions.
Sure, but my point was that Google didn't have an easier time as a result of Apple putting in the legwork - Google was first, neither is done, and others are far behind.
> Absolutely nothing needed to be upgraded in the payment terminals
You need to upgrade to support contactless payments, which was not previously a requirement to accept a payment method and not at all widely rolled out - in Denmark, contactless payments launched a year after Apple Pay released in the US, and that's despite Denmark generally being cashless and far ahead of US on credit card security stuff.
Contactless payment is still not universally supported, so upgrades are still pending.
Erm, we’re discussing NFC/RFID used for access control systems. That has literally zero to do with Apple Pay, beyond using some of the same hardware.
Just because you can perform a secure payment with your iPhone, doesn’t suddenly mean every crappy MiFare classic access control system has suddenly become secure.
They specifically write that this only supports UID based authentication. So, the card answers with the same unique ID every time.
UniFi has support for this, but seemingly not by default.
This solution also doesn’t allow you to clone an existing card. You actually need the admins to add the UID of your Chinese transport card to their system.
> Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.
No, basically all stored-value/transit cards and access cards use cryptographic two-way authentication, and for newer ones, the algorithms used are even decent (AES, 3DES etc.)
Essentially all old MIFARE Classic cards can be cloned with little effort these days, and some older access control and transit payment systems are still using these, but modern cards are much more robust.
In particular, I know unifi cards rotate keys. So you can’t simply clone them with a Flipper, and this also means third party cards don’t work. By default, this is true, but you can’t simply clone turn it off, as mentioned in the article.
Does this mean that the other systems’ cards are easily cloned? This seems very insecure, if so.