Why reading an RFID UID is not authentication
Most contactless readers deployed in the field do the simplest possible thing: they power up a card, ask for its UID, and send that number to a controller. If the number is on an approved list, the door opens or the charging session starts.
That is identification. It is not authentication, and the difference matters.
A UID is a serial number, not a secret
The UID is transmitted during anticollision, before any security step, in the clear. Anyone with a reader in range can read it, and inexpensive programmable cards and phone apps can transmit a chosen UID. A credential whose only secret is a value it broadcasts to anything that asks is not protected by that value.
This is why UID-only systems fail in a specific, predictable way: they do not fail at the reader, and they leave no trace. The cloned credential presents exactly what the genuine one presents, so the log records a legitimate user.
What cryptographic authentication changes
A credential that authenticates cryptographically never transmits its key. The reader issues a challenge, the card computes a response using a key held in its secure memory, and the reader verifies that response against its own copy of the key. A listener learns nothing reusable, and a cloned card body cannot answer.
The practical families:
- MIFARE Classic uses the proprietary CRYPTO1 cipher, which has been publicly broken for many years. Treat a MIFARE Classic deployment as UID-grade security regardless of whether sectors are “protected”.
- MIFARE DESFire EV1/EV2 uses standard cryptography with mutual authentication and per-application keys, and is the usual answer when a UID-only system has to be replaced.
- MIFARE Ultralight covers low-cost and disposable credentials, with capabilities that vary by variant.
Where the key lives is the real design decision
Cryptographic authentication only helps if the reader side of the key is protected. A key compiled into host firmware, or sitting in a controller’s flash, can be extracted from a single stolen unit — and in an EV charger or an outdoor access terminal, physical access to one unit is a realistic assumption.
A SAM (Secure Access Module) is a smart card in a small package, fitted inside the reader, that holds the key material and performs the cryptographic operations. The key is never present in host memory. Extracting it from a recovered unit means attacking the secure element itself rather than reading a firmware image.
This is the point at which reader architecture stops being a procurement detail. A reader with no secure element can still run cryptographic authentication — but only by putting the keys somewhere less safe.
What this means for an EV charger
In an OCPP deployment the charge point either checks the presented credential against a local authorization list or asks the backend to authorize it. Both paths make the same assumption: that the identifier arriving from the reader corresponds to the credential the user actually holds. If the reader only read a UID, that assumption does not hold, and neither the local list nor the backend can detect the difference.
Backend authorization is not a substitute for credential authentication. It answers “is this identifier allowed?”, never “is this the genuine credential?”. Sessions billed to a cloned identifier are authorised correctly by a system working exactly as designed.
Choosing between the two reader architectures
There are two sensible answers, and they suit different products.
The host owns the stack. The product already has a capable controller and a software team, and what it needs is the RF front end localised and supported. The AmbiTap NFC Reader Module is built for this: a 42 mm × 42 mm board on the NXP CLRC66303HNY front end, exposing host signals for integration behind a controller that implements the protocol and key handling itself.
The reader owns the stack. The product needs a finished reader that handles card technologies and key material so the host does not have to. The AmbiPay Secure NFC Reader supports MIFARE Ultralight, Classic, Plus and DESFire EV1/EV2 alongside ISO/IEC 14443 A/B, 15693 and 18092 and the NFC Forum tag types, and provides up to five hardware SAM slots — which is the part that matters for the problem described above.
Neither is more advanced than the other. The question is where the key material and the protocol logic belong in your system, and that is a decision to make before selecting a reader, not after.
Practical questions worth answering early
- Does the system authenticate the credential, or only read its identifier?
- If a single unit is stolen, what does the attacker learn?
- Are MIFARE Classic credentials already deployed, and is a migration path needed?
- Who holds the keys — the reader, the host, or a backend?
- Can credentials be revoked and rotated once units are in the field?