RFID cards: MyWay vs. MyWay+
I’ve previously written about Canberra’s legacy MyWay public transport card here. But now that they’ve introduced a new system and new card — let’s compare the two using my Proxmark3. I use the basic hf search, hf mf info and hf mfdes info to get the following outputs:
The old MyWay (MW) card:
[usb] pm3 --> hf search
🕛 Searching for ISO14443-A tag...
[=] ---------- ISO14443-A Information ----------
[+] UID: 1A 3E 4E 38 ( ONUID, re-used )
[+] ATQA: 00 04
[+] SAK: 08 [2]
[+] Possible types:
[+] MIFARE Classic 1K
[=] proprietary non iso14443-4 card found, RATS not supported
[=]
[+] Prng detection....... hard
[=]
[=] --- Tag Signature
[=] IC signature public key name: NXP MIFARE Classic MFC1C14_x
[=] IC signature public key value: 044F6D3F294DEA5737F0F46FFEE88A356EED95695DD7E0C27A591E6F6F65962BAF
[=] Elliptic curve parameters: NID_secp128r1
[=] TAG IC Signature: CC7597C526904424D2825603F50A423EBE561034E325BEF68D7073119BFDA1C0
[+] Signature verification: successful
[?] Hint: try `hf mf` commands
[+] Valid ISO 14443-A tag found
[usb] pm3 --> hf mf info
[=] --- ISO14443-a Information ---------------------
[+] UID: 1A 3E 4E 38
[+] ATQA: 00 04
[+] SAK: 08 [2]
[=]
[=] --- Tag Signature
[=] IC signature public key name: NXP MIFARE Classic MFC1C14_x
[=] IC signature public key value: 044F6D3F294DEA5737F0F46FFEE88A356EED95695DD7E0C27A591E6F6F65962BAF
[=] Elliptic curve parameters: NID_secp128r1
[=] TAG IC Signature: CC7597C526904424D2825603F50A423EBE561034E325BEF68D7073119BFDA1C0
[+] Signature verification: successful
[=] --- Keys Information
[+] loaded 2 user keys
[+] loaded 61 keys from hardcoded default array
[=] --- Fingerprint
[=] <n/a>
[=] --- Magic Tag Information
[=] <n/a>
[=] --- PRNG Information
[+] Prng....... hardNow the output for the MyWay+ (MW+) card:
[usb] pm3 --> hf search
🕚 Searching for ISO14443-A tag...
[=] ---------- ISO14443-A Information ----------
[+] UID: 08 96 90 3C ( RID - random ID )
[+] ATQA: 03 04
[+] SAK: 20 [1]
[+] Possible types:
[+] MIFARE Plus EV1 2K/4K in SL3
[+] MIFARE Plus S 2K/4K in SL3
[+] MIFARE Plus X 2K/4K in SL3
[+] MIFARE Plus SE 1K
[+] EMV
[+] NTAG 4xx
[=] -------------------------- ATS --------------------------
[+] ATS: 06 77 77 71 02 80 [ BE 6A ]
[=] 06............... TL length is 6 bytes
[=] 77............ T0 TA1 is present, TB1 is present, TC1 is present, FSCI is 7 (FSC = 128)
[=] 77......... TA1 different divisors are supported, DR: [2, 4, 8], DS: [2, 4, 8]
[=] 71...... TB1 SFGI = 1 (SFGT = 8192/fc), FWI = 7 (FWT = 524288/fc)
[=] 02... TC1 NAD is NOT supported, CID is supported
[=] -------------------- Historical bytes --------------------
[+] 80 (compact TLV data object)
[=]
[?] Hint: try `hf mfp info`
[?] Hint: try `emv reader`
[?] Hint: try `hf ntag424 info`
[+] Valid ISO 14443-A tag found
[?] Hint: try `hf mfdes` commands
[usb] pm3 --> hf mfdes info
[=] ---------------------------------- Tag Information ----------------------------------
[+] UID: 08 A4 4A 5D
[+] Batch number: CF 99 99 5D 80
[+] Production date: week 32 / 2023
[+] Product type: MIFARE DESFire native IC (physical card)
[=] --- Hardware Information
[=] raw: 04080130001305
[=] Vendor Id: NXP Semiconductors Germany
[=] Type:
[=] Subtype: 0x01
[=] Version: 30.0 ( Unknown )
[=] Storage size: 0x13 ( 1024 - 512 bytes )
[=] Protocol: 0x05 ( ISO 14443-2, 14443-3 )
[=] --- Software Information
[=] raw: 04080100021305
[=] Vendor Id: NXP Semiconductors Germany
[=] Type:
[=] Subtype: 0x01
[=] Version: 0.2
[=] Storage size: 0x13 ( 1024 - 512 bytes )
[=] Protocol: 0x05 ( ISO 14443-3, 14443-4 )
[=] --------------------------------- Card capabilities ---------------------------------
[=] 0.2 - DESFire Light, Originality check,
[=] --- Tag Signature
[!] ⚠ --- Card doesn't support GetSignature cmd
[+] ------------------------------------ PICC level -------------------------------------
[+] Applications count: 0 free memory n/a
[+] PICC level auth commands:
[+] Auth.............. NO
[+] Auth ISO.......... NO
[+] Auth AES.......... NO
[+] Auth Ev2.......... NO
[+] Auth ISO Native... NO
[+] Auth LRP.......... NO
[=] --- Desfire Light info
[+] Card have default (0xdf01) iso id for application
[+] Card in the LRP mode
[+] Card have LRP key in the MF/key1Let’s break it down and see what we have -
UID
MW = [+] UID: 1A 3E 4E 38 ( ONUID, re-used )
MW+ = [+] UID: 08 96 90 3C ( RID - random ID )The UID for the MW card is a fixed or static UID, whereas every time I ran a hf search on the MW+ card, it gave me a different UID — very cool. A randomized UID (RID mode) makes it very hard to clone or track because they’ll always respond with a pseudo-randomly generated UID. This also suggests the real UID for authentication is probably hidden behind some encryption on the card somewhere.
ATQA (Answer to Request, Type A)
MW = [+] ATQA: 00 04
MW+ = [+] ATQA: 03 04ATQA s a ISO 14443-A specific header that is a two-byte response from the card indicating its type and capability. It reveals basic information about the card such as it’s memory size, communication features and the card family type.
The first byte provides basic card family information e.g MIFARE Classic, DESFire, or Plus. For example, 00 indicates a card like MIFARE Classic or Ultralight, while 03 often refers to MIFARE Plus or DESFire.
The second byte gives additional protocol or capability details. For example, cards with 44 indicate compatibility with ISO14443-4 (used for extended data exchange).02 or 04 suggest the card supports advanced functionality (e.g., encryption or multi-application support).
In our case, the MW ATQA is a very standard MIFARE response where as the MW+ ATQA points to a more advanced card with higher security features like encryption and authentication - A good win for the MW+ card.
SAK (Select Acknowledge)
MW = [+] SAK: 08 [2]
MW+ = [+] SAK: 20 [1]The SAK tells us the card’s response during the anti-collision and selection process. This will reveal more or less the same basic information as ATQA but in a little more detail. The difference between the two is that ATQA helps the card reader know what kind of card is present and following that, the SAK helps the card reader know how to interact with itself. The way I understand it is that the ATQA tells the reader what it is, and then SAK will then tell the reader how to talk to it.
In the case of MW, 08 means it’s likely a MIFARE Classic 1K card which means it complies with ISO14443-A. The MW+ SAK response of 20 indicates a MIFARE DESFire / EV1 / EV2 card which supports ISO14443–4.
Some other examples include:
28: NFC-enabled Device00: MIFARE Ultralight18: MIFARE Plus SL138: MIFARE Plus SL3
The second value in the SAK refers to the number of bytes in the SAK response. [2] is typical of MIFARE Classic 1k/4k cards and means there might be some extra vendor-specific or extra protocol-related data, but it is often ignored by readers. [1] is the most standard response and is typical of MIFARE DESFire.
Possible Types
MW = [+] Possible types:
[+] MIFARE Classic 1K
[=] proprietary non iso14443-4 card found, RATS not supported
MW+ = [+] Possible types:
[+] MIFARE Plus EV1 2K/4K in SL3
[+] MIFARE Plus S 2K/4K in SL3
[+] MIFARE Plus X 2K/4K in SL3
[+] MIFARE Plus SE 1K
[+] EMV
[+] NTAG 4xxThrough a combination of the UID configuration, ATQA, SAK and the hf mf/mfdes info command that state it plainly — the MW card is MIFARE Classic 1k and the MW+ card is a MIFARE DESFire Light.
On face value, the new MIFARE DESFire MW+ cards are already going to be an improvement from the legacy cards but let’s compare the 2 protocols in more detail -
ISO 14443–3/4 Communication Protocols
The MW response confirms that the card does not support ISO 14443–4 but rather ISO 14443–3, meaning it cannot use secure APDUs (Application Protocol Data Units). APDUs are the data units (or “packets”) exchanged between a smart card (RFID/NFC card) and a reader. Since the MW card operates under ISO 14443–3, it has APDUs but they lack built-in encryption, meaning all communication between the card and reader occurs in plaintext.
This differs from the DESFire MW+ card, which does support ISO 14443–4, allowing for secure APDU communication to protect against eavesdropping and replay attacks. The presence of an ATS (Answer to Select) response in the MW+ output further confirms this, as ATS is required for ISO 14443–4 negotiation.
You can think of it as ISO 14443–3 being HTTP (unencrypted communication), while ISO 14443–4 is like HTTPS where there is secure communication. The new MW+ DESFire Light cards are clearly the better choice in terms of security.
Authentication and Key Management
MW = [=] --- Keys Information
[+] loaded 2 user keys
[+] loaded 61 keys from hardcoded default arrayAll MIFARE Classic 1k cards including our own MW card, rely on the insecure Crypto-1 encryption algorithm, a proprietary 56-bit stream cipher developed by NXP Semiconductors — the makers of the card. This algorithm has been broken since 2007, making key recovery and cloning possible. Interestingly enough, the MW system was launched in March 2011 — so this protocol was known to be vulnerable at the time.
Additionally, the presence of “61 keys from a hardcoded default array” strongly suggests that the card may be using pre-stored, well-known keys, which are publicly documented and usually easily exploited. Hardcoded credentials are a major security risk, as they allow attackers to bypass authentication without needing to break encryption.
MW+ = [+] ------------- PICC level -------------
[+] Applications count: 0 free memory n/a
[+] PICC level auth commands:
[+] Auth.............. NO
[+] Auth AES.......... NO
[+] Auth Ev2.......... NO
[+] Auth ISO Native... NO
[+] Auth LRP.......... NOThe MW+ response provides a PICC-level (Proximity Integrated Circuit Card) authentication check, showing that all authentication methods are locked down (NO) when queried by proxmark3.
Unlike MIFARE Classic, the MW+ (MIFARE DESFire Light) card enforces AES-128 authentication, ensuring secure challenge-response authentication. The lack of authentication responses (NO) indicates that Proxmark3 was unable to authenticate without valid keys, confirming that MW+ implements much stricter access control.
Anything else?
MW = [+] Prng detection....... hardI want to give half a point to the old MW card for trying — This line in the MW output makes it clear that the card uses a ‘hard’’ PRNG (Pseudorandom Number Generator) which means the card has a relatively non-predictable way of generating random numbers when authenticating or encrypting. This helps prevent nonce replay and key stream attacks.. but if the keys are hard coded then attackers will just use those to authenticate - rendering this useless. But half a point for the effort.
Also remember that the UID of the MW card was static meaning attackers can reliably clone the UID onto another card. Whereas the MW+ card uses a Random UID (RID mode) making cloning and replay attacks nearly impossible because the real UID is tucked away behind encryption.
MW+ = [=] --- Desfire Light info
[+] Card in the LRP mode
[+] Card have LRP key in the MF/key1The MW+ card also enables Limited Resource Protection (LRP) mode which is more evidence of the AES-128 encryption I’ve talked about and can also mean rate-limiting if multiple incorrect authentication attempts are detected — something really handy against brute force attacks.
Summing up
MIFARE Classic 1K cards are now widely recognized as insecure, regardless of any individual configurations. The vulnerabilities stem from the outdated ISO 14443–3 protocol, weak 56-bit Crypto-1 encryption, static UIDs, and the seemingly common practice of hard coding keys into the card itself. As a result, these cards are highly susceptible to cloning, key extraction, and replay attacks.
By upgrading to MIFARE DESFire Light, the ACT Government has significantly improved security across all aspects of the previous MW cards. DESFire Light implements AES-128 encryption, Random UID (RID mode) to prevent tracking, and Limited Resource Protection (LRP mode) to enhance secure communication. These improvements ensure strong authentication, data integrity, and protection against cloning and key recovery attacks.
