Mathew McBride's website

Frequently asked questions about NFC and myki cards

technologynfcmykiSun 17 Feb 2013 07:02:45No comments

Updated 20/2

Back in 2010, when I was first experimenting with NFC, I uploaded a file with information from a myki card to my website. According to the logs, it is one of (if not, the) most viewed pages on my site every month(!). More recently, after UltraReset appeared and some were asking if myki was vulnerable to it, I pulled out my NFC reader one lunchtime and found the answer (hint: nope!).

(The above article was mentioned on ZDnet, together with a response from the contractor of the myki system (KAMCO). I actually didn't notice it until someone reposted the link a few months later!)

These days one can find a similar information about any NFC card with an NFC smartphone and a suitable app - such as TagInfo by NXP. (Who are usually tight lipped about providing any useful technical information about their NFC products without an NDA)

In the interests of clearing some confusion about NFC, as well as satisfying the never ending curiosity surrounding myki, here is some information about the myki cards themselves, as well as a short FAQ

The myki card

myki cards are powered by NXP MIFARE DESFire series ICs - that contain an embedded 8051-type microcontroller, an embedded 3DES encryption engine and an operating system that allows one to maintain a filesystem on the card as well as handling authentication.

The current myki cards are the based on the original DESFire 4K product, and as far as I can tell, no cards based on the updated EV1 DESFire product are out in the wild. myki was one of the first ticketing systems to launch with DESFire, rather than the horribly insecure predecessor, MIFARE Classic.

The original DESFire model has been discontinued, and the last (official) delivery date was June 30, 2012. A brand new myki card I obtained last week had a manufacture date of Week 38, 2012 - this would indicate NXP were still manufacturing the original DESFire as of September 2012. Presumably, Kamco showed NXP a big bag of money in order to avoid a hasty transition to EV1! (which is supposed to be backwards compatible anyway)

(The manufacture date refers to when the DESFire IC was manufactured by NXP, a third party is responsible for embedding that in a plastic card and printing the artwork on the card)

The 3DES security imposes additional requirements for computing power on both the card and reader infrastructure which may explain part of myki's sluggish performance - i.e Transport for London (Oyster) noted slightly slower performance of their DESFire cards vs their old Classic-based cards (the numbers given by TfL are still a lot better than we're seeing on myki!)

Additional note: As far as I am aware, DESFire non-EV1 only supports 112bit keys (known as 2TDES), rather than the full 168-bit key. EV1 adds support for 168-bit (3TDES) as well as 128-bit AES. EV1 also adds a random UID feature which makes it harder to imitate a card. Some information on the changes here

Card structure

There are two applications (i.e folders) stored on a myki card - registed with the MIFARE Application Directory IDs 0xF21100 (#1) and 0xF210F0 (#2).

App #1 contains a 16-byte file hich can be freely read (without authentication), and changed with the master key. This probably stores some data written when the card was initialized - possibly the card PAN (3 08425 ..) - which is distinct from the burned-in serial on the DESFire.
Sample bits: c9 b4 04 00 bd 50 01 00 e1 d6 e7 df 10 00 04 10, c9 b4 04 00 a3 ed 78 00 16 52 46 68 10 00 04 10
There is another 16-byte file, classed as a "backup" file (two copies stored on the card). This file can be read freely, and written with key #3. Its purpose is unclear. Given the permissions I'd speculate it may be involved with card blocking and/or flagging other semi-permanent properties (registration status?) Sample bits: DC 0F 03 01 24 00 00 00 00 02 00 00 B1 16 18 AD
The pattern 03 01 24 00 00 00 00 02 00 00 seems to be common among all the (standard) cards I have.

App #2 also contains a 16-byte, world readable file:
Sample bits: 56 03 00 00 a0 7c 22 5f 1a 10 18 a2 85 0e 61 58, 56 03 00 00 a0 38 14 b8 da 10 18 a2 85 0e 61 58
This file has similar permissions to the file in app #1.
A freely readable 56-byte (backup type) is also stored in app #2, with write permissions assigned to key #3. This file appears to be the only (visible) change between touch on/off states.

File table

The file structure on the card is summarized in the table below:

File IDTypeSize (bytes)Keys requiredPotential use/comment
App #1
0x0FText16FreeMasterMaster#2Card PAN, type (adult/student/senior/staff/etc.)?
0x00Backup16Free#3#3#2Identifies blocked or registered cards?
App #2
0x0FText16FreeMasterMaster#2Card PAN, type (adult/student/senior/staff/etc.)?
0x00Backup56Free#3#3#2At least 12 bytes modified during a touch on/off (see note below). Byte 7 = touch off (0x10) / on (0x11,0x12,0x13) ?
0x01Cyclic32*10#4#4#3#210 records - previous trip history
0x02Cyclic32*5#4#3#3#25 records - previous top ups
0x03Value file32#4#4#3#2Current dollar balance of card. Min/Max value: +/- 214783647 (yet max myki money is $999.99 ?). Probably stored in cents (no floating point). Limited value top ups allowed from key #4, appears to be up to value of "350" (but set to "0" on a brand new card)
Total (logical) size1.2K

* Minimum block size on DESFire is 32 bytes; actual size on flash is (probably) higher than estimated above. Backup files are text files that are stored twice for redundancy.

Sample of Modified bytes in App #2 file 0 after touch on:

-[0000] DC 0F 03 01 DC 0F 00 10 |........|
-[0008] 00 00 00 00 01 01 00 13 |........|
-[0010] 48 00 00 00 00 00 88 00 |H.......|
+[0000] DC 0F 03 01 DC 0F 00 11 |........|
+[0008] D2 00 00 00 01 01 00 13 |........|
+[0010] 48 01 04 02 00 13 88 00 |H.......|
 [0018] 00 00 00 00 98 00 00 00 |........|
 [0020] 00 00 A8 00 00 00 00 00 |........|
-[0028] B8 00 00 00 00 00 C8 00 |........|
-[0030] 02 00 02 00 74 5C 5A 67 |....t\Zg|
+[0028] B8 00 00 00 00 00 C8 02 |........|
+[0030] 04 00 03 00 43 47 8D CA |....CG..|
 [0038] 00 00 00 00 00 00 00 00 |........|

Key security:
(Guessed) key configuration:

  • Key #2: Set as change permissions/delete key, key 'thrown away' - no need to change the structure of the card outside development
  • Key #3: Write key - would be present in everything but a myki check device
  • Key #4: Read key (yet has ability to change balance by a limited amount?)

Presumably some level of key diversification is performed so if you were to find the keys for your own card, it would not be relevant to other cards.

The devices that can be used for myki are legislated - and an 'operational smart card access module' mandated for each. I take this to mean they are using some sort of SAM - which explains the SIM card slots visible on pictures of myki hardware previously posted on the internet (at the defunct

Short term tickets:
myki short term tickets are only available in the regional cities that got myki (in a fully installed state) before Melbourne did; their use in Melbourne was cancelled by the Bailieu Government (based on a TOP SECRET report by Deloitte), but no signs have been forthcoming about when they will be eliminated from the regional cities.
UPDATE: It was announced to the myki customer experience panel on the 18th of February that Short Term tickets are to be phased out by the end of March.

The short term tickets - as mentioned in the previous post are MIFARE Ultralight based. There are no encryption features on this chip; the newer Ultralight C and EV1 does have some capabilites in this area. The Ultralight can be set to lock certain bytes from further writing (i.e the ticket zone and expiry can be locked), and this is what myki has done. (The UltraReset app works on systems that fail to do this). That said, it would be possible to guard the cards against manipulating by hashing their contents - and I suspect this explains the seemingly random string of bytes at the end of the STTs.

Frequently Asked Questions

There is an exploit for the DESFire, is it feasible to manipulate my card to give me an unlimited balance?
Yes, there is a rather cool attack out there (using TEMPEST like techniques, such as power analysis), but in my opinion, but this is far from the simplicity of the attacks on the MIFARE Classic cards (some of which work in less than a minute!). Even if you recover the key(s) for your card, key diversification means your results are only applicable to one card, and giving yourself lots of money should get noticed on the backend - where they will block your card.

Is cloning cards feasible?
No. For starters, you can't just copy the contents of one card to a blank card and have a true copy afterwards - the card serial number is burned in, and any decent system would recognize this. You can get 'clone' cards for the MIFARE Classic that have changeable UIDs, but this can be countered by detecting any 'quirks' the clone cards may have (i.e there is a quirk in the aforementioned Classic-1K clone when it identifies itself). The manufacturer may have undocumented commands in the firmware of genuine cards that could be used to differentiate them from imitations in the future.
If you really want to fool an NFC system, you need to 'bit-bang' NFC frames using hardware such as the ProxMark. I think any authorized officers who see you using one of them will do more than just write you a ticket!

Can I copy my NFC card to my smartphone? / Can I use my smartphone to emulate an NFC card
No. To add to what is mentioned in the answer above, for starters, while it is possible to emulate an NFC tag using off the shelf NFC IC's, these are crippled so the UID of any emulated card, from userspace, is masked - making it really obvious to a reader the 'card' it is talking to is an emulated one.
The way NFC cards are emulated on a smartphone, for uses such as Google Wallet, is by the use a of 'secure element' attached to the NFC chip - this can be something like a dedicated chip, or another piece of hardware such as a (micro-)SD card or SIM card. The secure element contains the program for the emulated card in the form of a JCOP applet. Basically, they take the IC used on your contactless credit/debit card (payWave,payPass etc.) and attach it to the NFC reader, allowing it to access the NFC interface as required.
While it is possible to program JCOP applets that mimic the behaviors of other NFC tags, the cards will identify themselves as being JCOP cards, and a properly programmed NFC system would only communicate with card types it expects to talk to.

Would it be possible for myki to release an app so I can use my NFC smartphone as a myki card?
Yes, an example is Snapper over in Wellington - they took the step of migrating to JCOP some years back, so porting to NFC smartphones was easy. But, as you can see, you need a special SIM, on a particular operator to do this. They could do this without operator help using the inbuilt secure element on some phones (i.e the Google Nexus, used for Google Wallet), but as a whole, the entire card emulation/secure element features are a minefield which has been made difficult to navigate by vested interests (such as the payment card companies and mobile operators - we can't have third parties setting up 'over the top' payment applications set up without giving the operators a cut, can we?)
Transport for London has considered porting Oyster to NFC phones, but they appear to be waiting for the technology to speed up first.
The other possibility - and the more compatible one - is to use Peer-to-Peer NFC - which is enitrely different to card-based NFC - the procedure to communicate under P2P is rather complex. Not to mention, any such implementation would live entirely in a phones userspace - a security nightmare.

(I found a rather good explanation on Quora which explains the issues around ownership of the Secure Element more clearly.)

Would it be possible for someone to write an app that shows my myki card history and/or balance by reading the card, as with other systems (i.e FareBot)?
From what has been posted above, the card balance and history is encrypted, you would need to obtain key #4 to read them. File 0 in app #2 is plaintext and appears to be modified on touch on/off - this might have details on the current fare zone, trip origin etc.
(Personally I think having the entire travel history world readable is very bad from a privacy point of view. Someone could read your card when you aren't looking and deduce your travel routine. That said, perhaps PTV could have a mechanism for registered users to obtain a read-only key for their cards)

Is there any technical reason for myki to have the 'Multiple cards detected' 'feature'?
No.. and (maybe) yes. There are defined procedures (known as 'Anticollision') to handle cases where there are multiple cards in the field of the NFC reader. Part of the rationale behind having registered application IDs (the Mifare Application Directory) is so a reader can find the card it wants, among a set of cards, fairly quickly. So this can definitely be done.
.. but, there may be other limitations at play. The NFC reader ICs I work with - the NXP PN532, will only deal with two cards in the field at once, and can be rather erractic when multiple 'advanced' cards (i.e JCOP and DESFire) are in play. From a system operators point of view, it could make sense to enforce or encourage a certain behavior to prevent slow downs that could arise from these cases.


  • The developers of nfc-tools/libnfc/libfreefare - without this freely available toolkit, information about these particular NFC tags would be a lot harder to come by.
  • NXP and their excellent TagInfo app - which has filled in a lot of gaps (which otherwise would've been hidden under an NDA)

And to conclude, here is an interesting article about the creators of FareBot - which reads history from Seattle's ORCA card, among others.

Disclaimer: I am not associated with any firm doing NFC, payments or transport ticketing. (Nor, have I ever been). All of the information here can be deduced with publically available documentation and tools. I am also not, in any way, a computer security expert, and have made no attempt to find or test potential vulnerabilities.

Your email address will not be published

Please retry reCAPTCHA

Welcome to my site

Mathew McBride, telecoms hardware access engineer, programmer, gamer and all round nerd

Warning: contents of blog may not make any sense whatsoever.

ipv6 ready

You are accessing this page over IPv6!

(C) Mathew McBride, 2006-2017
Creative Commons License
Unless specified, the content on this website is licensed under a Creative Commons Attribution-ShareAlike 3.0 Australia License.