RFID: A closer a look at Canberra’s MyWay transport card

If you’ve ever been curious about Canberra’s public transport card - I’ve used my Proxmark3 to take a somewhat deep dive into what’s going on ‘under the hood’.

Before any of that here’s a TL;DR for the RFID fluent:

• Card Type: MIFARE Classic 1K.
• UID: is in fact not unique — (ONUID - possibly reused, not unique).
• ATQA: MIFARE Classic identification.
• SAK: Indicates MIFARE Classic with no advanced ISO 14443-4 features.
• Protocol: Proprietary (NXP Semiconductors), non-ISO14443–4 (RATS not supported, limited functionality).
• PRNG Detection: Hard
• IC Signature: Verified as authentic after successfully using NXP’s public key and elliptic curve NID_secp128r1.

In short, it’s likely that you can clone these cards but without understanding how authentication is done behind the scenes at the card reader— it’s difficult to say whether you could get a WORKING clone since there looks to be the data on the cards to perform such authentication checks but whether or not that happens is another story.

If you would like more detail, please read on —

After placing the card on my HF antenna, I run:

hf search

Which produces the following output:

[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

Here’s what all this means line by line -

1. [usb] pm3 → hf search

hf search is the command I ran to scan for high-frequency (HF) tags with my Proxmark3. High frequency in the RFID world is 13.56MHz and is pretty much the standard frequency for most public transport, access control and contactless payment systems around the world.

2. — — ISO14443-A Information — —

A quick brief on the ISO14443-A before we dive in: It is part of the ISO/IEC 14443 standard, which defines the communication protocols for proximity contactless smart cards, such as this one.

ISO 14443-A specifically refers to a type of modulation, communication protocol, and anti-collision method used in proximity smart cards. It is one of the two primary variants of the ISO 14443 standard, the other being ISO 14443-B.

If we didn’t know anything about this card, other than that it uses this protocol we would know —

• That it is indeed a HF card, operating at 13.56MHz
• A range of 2 to 10cm depending on the card and/or reader
• Uses Amplitude Shift Keying (ASK) modulation
• ‘card-to-reader’ communication is encoded using Modified Miller encoding
• A rough idea of it’s Data Transfer Rate (Most commonly used it 106kps)
• Uses a proprietary anti-collision algorithm to ensure that only one card is processed at a time when multiple cards are in the reader’s field.

As these are all mandated by the protocol itself.

3. UID

[+]  UID: 1A 3E 4E 38  ( ONUID, re-used )

This is simply a Unique Identifier (in hexadecimal) that identifies my particular card. Ironically what I discover is that this is a Non-Unique ID.

The ‘ONUID, re-used’ suggests this is either a card with a default or non-unique UID or a card that may have been reprogrammed to reuse the same UID multiple times.

After some research I found this is pretty common for public transport cards. For large-scale deployments (like in public transport systems), it’s an exercise in cost-saving by the manufacturer and the 4-byte UID space can run out quickly or get reused across batches of cards, especially if the public transport system is used by millions (Maybe not in Canberra’s case though).

What I am assuming here is that Transport Canberra don’t rely solely on the UID for identification. Instead, they might be storing additional unique information in the card's memory sectors to identify my card as in fact my card.

4. ATQA

[+] ATQA: 00 04

Answer to Request, Type A (ATQA): This is 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).

Here are some examples:

• 00 04: MIFARE Classic 1k/4k (Our card!)
• 00 02: MIFARE Ultralight
• 00 03: MIFARE DESFire
• 03 44: MIFARE Plus (SL1)
• 03 02: MIFARE Plus (SL3)
• 00 44: NFC Forum Type 2 Tag
• 03 00: MIFARE DESFire EV2
• 04 00: ISO14443–4 Compliant Card
• 08 00: Calypso Transport Cards

5. SAK

[+]  SAK: 08 [2]

Select Acknowledge (SAK): This is the card’s response during the anti-collision and selection process. This will tell us basic information on the card type and it’s specific communication capabilities.

My first question was how this was different to ATQA, and here’s how I understand it —

The purpose of ATQA is to provide basic card information during initial detection such as card type where SAK’s purpose is to confirm (..acknowledge) card selection and make’s the reader aware of it’s specific communication capabilities, such as support for ISO14443–4 or specific encryption.

In simpler words, ATQA helps the reader know what kind of card is present, and following this SAK helps the reader know how to interact with the selected card.

In our case, 08 means it’s likely a MIFARE Classic 1K card that complies with ISO14443-A but does not support ISO14443–4 (A higher level protocol used by advanced cards like DESFire).

Some other examples include:

• 20 : MIFARE DESFire / EV1 / EV2
• 28 : NFC-enabled Device
• 00 : MIFARE Ultralight
• 18 : MIFARE Plus SL1
• 38 : MIFARE Plus SL3

[2] indicates the number of bytes in the SAK response. In our case, this suggests that the card has transmitted its full UID, the anti-collision is complete and the card is ready for further basic communication.

A [1] means that the card sent part of it’s UID (if it has a multi-byte UID) and a [3] here would indicate that the card supports ISO 14443–4 for advanced protocols and the reader would need to send a RATS (Request for Answer to Select) to begin extended communications.

6. Possible Types

[+] Possible types:
[+]    MIFARE Classic 1K

This is essentially taking everything the Proxmark3 (and now we) have learnt from the last few lines and confirms that the MyWay card is likely a MIFARE Classic 1K card. An expected result since many public transport control systems utilize this type of card type, especially aging ones.

7. “Proprietary Non ISO14443–4 Card Found, RATS Not Supported”

[=] proprietary non iso14443-4 card found, RATS not supported

A ‘Proprietary Non ISO 14443–4’ card again suggests that this card complies with ISO14443-A because it does not follow the ISO14443–4 protocol for higher-level communication. Instead, the card uses a proprietary (usually custom / vendor specific) communication protocol beyond just the basic ISO 14443-A framework. In our case, likely a proprietary implementation of ISO14443-A from NXP Semiconductors as seen later in the output.

We also learn that the card does not support RATS (Request for Answer to Select). RATS is used in more advanced ISO14443–4 cards for additional data exchange. Knowing that this card is a MIFARE, this is an expected result.

8. PRNG Detection: Hard

[+] Prng detection....... hard

PRNG (Pseudo-Random Number Generator) is used in RFID cards to generate random numbers during authentication and encryption. These numbers help encrypt communications between the card and reader. If the PRNG is weak, attackers can predict these numbers, which allows them to break authentication without knowing the encryption key.

Here we see that it’s ‘hard’ — meaning the random numbers it generates are unpredictable. A weak PRNG would allow attackers to capture authentication data from a valid session, replay or predict the same numbers in another session, and/or break authentication and extract keys without brute-forcing.

However, while a hard PRNG is better, it’s ultimately redundant here because MIFARE Classic 1K still uses the broken 56-bit Crypto-1 encryption algorithm. This means attackers can still recover keys and clone the card using different attack methods anyway.

9. IC Signature

[=] --- 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

An Integrated Circuit (IC) signature is a cryptographic signature created by the manufacturer of the chip. It is used to verify the authenticity of the card by allowing a reader (Like my Proxmark3 or Transport Canberra’s tap on/off readers) to confirm that the chip is genuine and not tampered with. It can’t be easily forged either.

• IC Signature Public Key Name: This indicates that the public key used to verify the signature corresponds to an NXP MIFARE Classic chip. A chipset from a Dutch company called NXP Semiconductors.
• IC Signature Public Key Value: This is the public key (in hexadecimal) that was used to verify the digital signature.
• Elliptic Curve Parameters: NID_secp128r1 is apparently a pretty standard elliptic curve from the SEC (Standards for Efficient Cryptography) group in these kinds of public transport systems. The way I understand it is that the curve defines the cryptographic operations, and the bit-length indirectly reflects the curve’s resistance to attacks. A well-chosen curve ensures that the signature cannot be reasonably forged or broken. A cloned card may be able replicate a UID, but without the correct IC signature as well, an authenticating reader might not accept the card. While a 256-bit curve would offer stronger protection, the 128-bit curve chosen is likely sufficient.
• TAG IC Signature: This is the digital signature retrieved from the card — It contains the signed data (e.g., UID) and the cryptographic proof that the card is authentic.
• Signature Verification: This confirms that the card is authentic — It’s an authentic NXP Semiconductor chip and not a clone.

Conclusion

The MyWay card certainly has vulnerabilities, not due to any specific configuration or fault of their but rather it’s outdated technology and protocol use.

It’s likely these cards can be cloned but it’s also likely that the card readers mitigate this risk through multiple checks, such as verifying the IC signature and/or UID. Since the IC signature is difficult to forge, the combination of a valid UID and IC signature would prevent most cloning attempts.

Additionally, the use of a non-unique UID (ONUID) suggests that other data stored on the card may play a role in authentication. This points to the possibility that the card’s identity is validated by more than just the UID, possibly through a combination of the UID, IC signature, and some other data on the card perhaps.

As I’m writing this they are transitioning to a new system called MyWay+ which I think you can use your credit / debit cards as a ticketing. However, the modernizing of the system will surely bring stronger security systems, processes and checks that mitigate the well known MIFARE weaknesses…. right? (Edit: YES!)