AXON Reader
A 13.56 MHz DESFire EV3 reader that makes the card prove its key with AES-128 before it reports anything, then hands the event to the AXON master over an encrypted RS-485 link. One board, one firmware — in the cabin or at every landing.
Reads, proves, reports — never decides
AXON URX-Secure is the credential-capture end of the AXON system. An ST25R3916B front-end on SPI energises the field at 13.56 MHz and an STM32G031 (Cortex-M0+) reads the card's real 7-byte UID from anticollision. The reader then selects the AXON ACCESS application (AID F5 10 02), derives that card's read key from its UID with AES-CMAC and runs a DESFire AuthenticateAES. A card that cannot answer — a copied UID, a MIFARE Classic clone, a foreign DESFire — fails here and, by default, produces no reaction at all. The reader never writes to a card and never grants on a UID alone.
What leaves the reader is a CARD_EVENT frame on RS-485 — half-duplex, 115200 bps, 8N1 — carrying the UID and an AUTH_OK flag inside the AXON binary protocol (SOF 0xA5, addresses, command, length, CRC16-CCITT). On top of that frame layer runs the secure layer v2: a DESFire-style mutual handshake between reader and master, a per-session key, and every access frame encrypted with AES-CTR then tagged with an 8-byte CMAC and a per-direction counter. A replayed or forged frame is dropped. The master looks the UID up in its local database, decides offline, and answers ACCESS_RESULT within one second.
The same board and the same firmware image serve two positions: inside the cabin, on RS-485 to the cabin master (AXON CCU-32), or at each landing, on RS-485 to the floor Node which bridges to the external master over CAN. Only the bus address differs, fixed at build time. The reader shows what happened — blue link up, magenta link down, white while awaiting a verdict, green or red held for three seconds — and the master can silence the buzzer or enable UID-only reporting over an authenticated SET_CONFIG. Firmware is spec-compliant and bench-verified; final testing continues on secure-element key storage.
What the board does for the site
DESFire EV3 mutual authentication
Every tap runs SelectApplication on the AXON ACCESS app, then AuthenticateAES with the card's own key1. Identity is the 7-byte manufacturer UID, but it is trusted only after the AES exchange succeeds. Random UID is off, so no extra GetCardUID round-trip is needed.
Per-card diversified keys
Keys follow one root: root to a READ sub-master per application, then AES-CMAC over the UID to a per-card key. The reader holds only that READ sub-master — it can authenticate any AXON card but cannot format, rewrite or re-key one, which bounds what a stolen reader can do.
Encrypted, authenticated RS-485
Reader and master run a DESFire-style 3-pass mutual authentication (four frames, AES-128-CBC over a shared link key) and derive a session key. CARD_EVENT, ACCESS_RESULT and SET_CONFIG are AES-CTR encrypted, then MAC'd with an 8-byte CMAC over a 4-byte counter — encrypt-then-MAC. Counters are per direction, so replays and reflections are rejected.
The master decides, offline
The reader forwards the authenticated UID; the master checks it against the card database in its own flash plus the floor or door permission for that reader address, drives its relays and replies. No server sits in the decision path. If no verdict arrives within one second the reader shows deny.
One firmware, cabin or landing
Cabin readers talk RS-485 to the CCU-32 cabin master; landing readers talk RS-485 to the floor Node, which relays to the external master over CAN. Same hardware, same image, same wire protocol on both masters — only the build-time bus address changes, so one SKU covers a whole building.
Link-aware feedback and config
The idle LED reports the master link: blue when an authenticated frame arrived within 3 s, magenta when not — and cards are not accepted while the link is down. Grant is green plus a beep, deny red, each held 3 s. The master can set SILENT or READ_ALL at runtime over secured SET_CONFIG.
One tap, from antenna to relay
Card enters the field
The ST25R3916B detects a card at 13.56 MHz and raises IRQ; the STM32G031 reads the real 7-byte UID over SPI from anticollision.
Card proves its key
SelectApplication F5 10 02, derive key1 from the UID, AuthenticateAES. A card without the key fails and, by default, the reader shows nothing and sends nothing.
Event to the master
The reader sends CARD_EVENT with the UID and AUTH_OK in an encrypted, MAC'd frame, blinks white and waits up to 1 s for a verdict.
Master decides, reader shows
The master checks the UID in its local database and that reader's floor or door permission, drives its relays and answers ACCESS_RESULT — green and a beep, or red.
RS-485 to the master, protected at three layers
RS-485 half-duplex
A MAX3485-class transceiver on USART1 with driver-enable switched by the peripheral itself, so the reader releases the pair cleanly before the master answers. 115200 bps, 8N1. Terminate with 120 Ω at both physical ends and daisy-chain the readers — no star wiring. The reader is a slave: it only speaks after a tap or when polled.
115200 bps 8N1 · DE/RE auto · 120 Ω endsAXON binary protocol with CRC16
Each frame is SOF 0xA5, destination, source, command, length (0–64), payload and a CRC16-CCITT (0x1021, init 0xFFFF) over everything after the SOF. Broadcast is 0x00, the master 0xFE, the reader's own address a build-time constant. Commands include PING/PONG, GET_VERSION, SET_LED, BUZZ, CARD_EVENT, ACCESS_RESULT and SET_CONFIG.
SOF 0xA5 · CRC16-CCITT · 64 B payloadMutual auth, then encrypt-then-MAC
Modelled on DESFire AES auth: a 3-pass mutual authentication (four frames over a link key) yields a 16-byte session key and resets the counters. Access frames are AES-CTR encrypted with a 12-byte trailer — 4-byte counter plus 8-byte CMAC. The master re-keys every 5 min, the reader caps sessions at 15 min; eight bad frames trigger a 5 s lockout.
AES-CTR + CMAC-8 · anti-replayThe numbers, from the datasheet
Bus, cryptography and MCU values come from the reader firmware and the AXON system spec (June 2026); enclosure and supply figures come from the product catalogue.
| Role | Credential reader — reports, does not decide |
|---|---|
| MCU | STM32G031C6T6, Cortex-M0+, 32 KB flash / 8 KB RAM |
| NFC front-end | ST25R3916B, 13.56 MHz, SPI ~4 MHz |
| Positions | Cabin (to CCU-32) or landing (to Node) |
| Bus address | Build-time constant, default 0x01 |
| Firmware | Axon-encrypted-readerV1.0 |
| Card platform | NXP MIFARE DESFire EV3 (AES, ISO 14443-4) |
|---|---|
| Identity | 7-byte manufacturer UID, trusted only after auth |
| Application | ACCESS AID F5 10 02, key1 (READ) |
| Card authentication | DESFire AuthenticateAES, AES-128 |
| Key derivation | AES-CMAC diversification from UID (AN10922-style) |
| Non-AXON cards | Ignored by default; UID-only report with READ_ALL |
| Originality check | ECDSA secp224r1 (Read_Sig) — optional step |
| Bus | RS-485 half-duplex, 115200 bps, 8N1 |
|---|---|
| Transceiver | MAX3485-class, DE driven by USART1 |
| Frame | 0xA5 SOF · DST · SRC · CMD · LEN · payload · CRC16 |
| CRC | CRC16-CCITT, poly 0x1021, init 0xFFFF, LE |
| Payload | 0–64 bytes |
| Termination | 120 Ω at both bus ends, daisy-chain |
| Programming | SWD (SWDIO/SWCLK) |
| Handshake | 3-pass mutual auth (4 frames), AES-128-CBC, link key |
|---|---|
| Session key | 16 B from RndA/RndB; 5-min re-key, 15-min max age |
| Frame protection | AES-CTR + 8-byte CMAC + 4-byte counter |
| Liveness | Authenticated SEC_PING/SEC_PONG, < 3 s |
| Lockout | 8 bad secure frames → 5 s ignore |
| Key storage | Software AES today; ATECC608 slot planned |
| Secrets on reader | READ sub-master only — no root, no admin key |
| Input | 9–15 V DC |
|---|---|
| Consumption | < 2 W typical |
| Logic supply | 3.3 V on board |
| Enclosure | IP20 indoor / IP65 outdoor variant |
|---|---|
| Indicators | RGB LED (common-anode), passive buzzer |
| Feedback | Green/red held 3 s; blue link up, magenta link down |
| Secure element | ATECC608 footprint on I2C1 |
Terminals & MCU pin map
Differential pair to the master via the MAX3485-class transceiver. USART1 TX/RX on PA9/PA10, driver-enable on PA12 handled by the peripheral. Twisted pair, 120 Ω at both bus ends.
Supply input, 9–15 V DC per the catalogue; the board logic runs at 3.3 V. Sharing a 12 V access rail is acceptable if it is sized for the combined load.
ST25R3916B on SCK/MISO/MOSI PA5/PA6/PA7, software chip-select PA4 (active low), IRQ on PA0 (rising edge). SPI mode 1, about 4 MHz.
PB0/PB1/PB2, active low, common-anode RGB. Colours are the reader's only status output: link, awaiting, grant, deny.
PB3, PWM from TIM1_CH2 driving a passive buzzer. Grant and deny tones; fully suppressed when the master sets the SILENT flag.
PB6/PB7 to the secure-element footprint. Not used by the current build; planned home for the READ sub-master and the link key.
SWDIO/SWCLK on PA13/PA14 for programming and debug. Bus address and secure-layer options are build-time constants.
How URX-Secure compares
| Aspect | AXON URX-Secure | Typical alternatives |
|---|---|---|
| Credential on the wire | AES-authenticated UID inside an encrypted, MAC'd RS-485 frame | 125 kHz / Wiegand: credential in the clear, clonable in seconds |
| Panel lock-in | Native AXON protocol on the same RS-485 bus as the rest of the system | OSDP Secure Channel: encrypted, but tied to OSDP-capable panels |
| Decision path | Local master decides from its own flash, offline | Cloud-panel readers: an internet outage is an access outage |
| Credential type | Card-based DESFire EV3, the realistic baseline for residents and staff | Mobile-only NFC/BLE readers: no smartphone, no access |
AXON Reader, up close
Where AXON URX-Secure fits
Typical configurations we size for integrators. Every scenario below is a planning example, not a customer reference.
One reader in the cabin, floors gated per resident
A URX-Secure sits inside the cabin on RS-485 to an AXON CCU-32. A resident taps, the card authenticates, and the cabin master enables only that resident's floor buttons through its relays. The database lives in the cabin master's flash, so a dead internet link changes nothing at the tap.
Landing readers, per-tenant floor permission
Each landing gets a URX-Secure on RS-485 to that floor's AXON Node, which bridges to the external master over CAN. Tenant cards carry permission only for their floors; the reader address tells the master which landing was tapped, and the verdict returns within the reader's one-second window.
Outdoor variant at the gate, indoor in the lobby
The IP65 variant covers a pedestrian gate and garage entry, the IP20 variant the lobby door. Same electronics, same bus, same encrypted frames. Long RS-485 runs back to a service room are the reason the link is authenticated end to end: a tapped or replayed bus frame is simply dropped.
Migration without a hard cutover
A building still holding legacy MIFARE Classic cards enables READ_ALL so the reader reports those cards UID-only, flagged not authenticated, for the master to log while DESFire EV3 cards are issued as the replacement. The reader itself never grants a UID-only card; the master's policy sets what the transition window means.
AXON URX-Secure FAQ
Does the reader decide whether a card has access?
Which cards does URX-Secure support?
Is it the same reader inside the cabin and at the landings?
Can it feed a legacy Wiegand panel?
What stops someone tapping the RS-485 bus and replaying a grant?
Is URX-Secure shipping today?
The rest of the AXON system
Ready to specify AXON URX-Secure?
Tell us how many cabins and landings you have and which master sits behind them. We will size the RS-485 segments, reader addressing and card provisioning for the site, and arrange a pilot reader for bench testing against your master.