How difficult is it to clone MIFARE Ultralight EV1 chips? You mention the UID is signed, can you simply copy this signature? Do you just need to buy one of the magical chips of the same design, that allow uid/serials to be written?
What is the actual mechanism behind the DESFire and other secure NFC chips that prevents cloning?
I haven't really looked into the security aspects. I think that you could clone one of the Ultralight chips, but it wouldn't gain you anything because the security is in the backend. It's a lot like a printed concert ticket or boarding pass. You could print as many as you want, but the ticket is still good for just one admission.
The DESFire and other secure chips contain a cryptographic key that you can't access. Without the key, you can't make a clone of the chip. The cryptography provides authentication and encryption that you don't get with the cheap Ultralight chip.
I think this is all market segmentation; they don't put more security into the Ultralight chip because they don't want to cannibalize their higher-end sales.
Ultralight supports password authentication, and you can diversify the password from the serial number, meaning that until that password is revealed by a legitimate reader as part of a validation transaction (at which time the ticket is invalidated anyway), you can't clone it.
Ultralight C does support actual cryptographic authentication.
I don't think the password authentication helps against cloning. You could start a transaction and stop after you get the password. Then you could clone the card. (The system could invalidate the ticket as soon as they get the UID, but that would be a reliability nightmare since a failure during the read would invalidate someone's ticket.)
You could do that, but it still greatly raises the cost for an attacker, since they need to hang around a ticket validator for every ticket they want to clone, as opposed to e.g. a QR code ticket, which can be trivially copied by a simple screenshot.
Also, many of these transit systems are eventually consistent (they're usually offline-capable for resilience, but usually manage to send all validation transactions to a backoffice system within at most a day, and often minutes).
This allows detecting duplicate usage fairly quickly. In systems where you need to tap out as well as tap in to leave the turnstile, that's where ticket inspectors might take a sudden interest in you if you tap out with a cloned ticket.
In the end, as with most security systems, the goal is not to make fraud absolutely impossible, but to make it economically non-viable.
In general, the card emulation devices (e.g. the chips in phones) try to avoid letting any arbitrary UID be set. This makes cloning these cards more difficult than it would otherwise be. It’s not terribly difficult to find devices (USB-connected things and battery-less cards) that do allow arbitrary UIDs to be set, though.
> the card emulation devices (e.g. the chips in phones) try to avoid letting any arbitrary UID be set.
I can't think of a much worse way to do security. That feels like trying to flood the market with lockpicks that don't work instead of making a more pick-resistant lock.
I imagine this is because the locks contain chips from NXP (PN532 chips), the name-brand MIFARE chips are made by NXP, and the lock picks (also PN532 chips!) are made by NXP.
Is this the same system used by Boston MBTA? I was surprised to see single-use tap cards when I visited there for the first time yesterday. I wondered why the ticket isn't reloadable.
Most people who live in Boston use the reloadable CharlieCard (https://www.mbta.com/fares/charliecard) - these report as Mifare Classic 1k, which is a similar chip
There are single-use fares as well, the "CharlieTicket" that you might've encountered.
Yeah I figured but you can't buy a charliecard online to load into your smartphone wallet, and I only needed it the once, and since it took more than an hour to get to Cambridge due to some combination of circus acts I used Blue bikes for the remainder of the day.
Ah yes, it's not quite there, but almost. Contactless payment directly at the turnstile is coming to Boston MBTA this year, I believe. Like how NYC works now, where you can just use your credit card for entry.
This is the London system we’ve had for a decade, it was licensed to other areas a few years ago.
I found myself in Paris having to cross the other day and forgot how terrible the old way of buying tickets was, amazed that it’s still the norm in so many cities
Single tap cards are usually just used with their "hardwired" chip serial number. That is stored in a central system which invalidates the number once you used it. This makes it rather easy (even if its environmentally unfriendly) to issue these cards: load a number of cards into your machine, register the serial number and invalidate it when used.
That's no longer the case: Many of the newer single-use ticket ICs (including the MIFARE Ultralight one mentioned in the article) actually support data storage and (very) basic cloning protection.
That the chips support data storage doesn't mean that that feature is used. There are systems that use MIFARE Ultralight cards for the UID alone just because they are cheap and easily sourced.
While it is possible to use advanced features from newer chips, I know more than one actual system where they just use the serial number, even when rolling out more advanced Mifare based cards. So your "that's no longer the case" is a bit too general/optimistic IMO.
And sure, simply using the serial number might pose a security risk depending on the application, but that rarely stops implementors to implement such schemes. More often than not do people believe in security by obscurity, sigh. For a simply ticket system the serial number should be secure enought as it is a use-once application.
I am interested in the plastic layer with conductive traces for the antenna. How are these made? Do you know of a source that talks about the production process for them?
For MIFARE Ultralight, yes – it's essentially just a bearer token with no encryption/authentication. I believe there's a password mechanism, though, which might just be good enough for single-use tickets. That password can be derived/diversified from the card's serial number, making such a scheme still significantly better than e.g. simple QR codes.
MIFARE Ultralight C and larger/more expensive chips allow challenge-response authentication, making them pratically uncloneable. These are usually used for reloadable and monthly passes.
How does this fit into the broader NFC ecosystem? What do other big metro systems like Omny, Clipper, Smartrip etc use? Apple and Google seem to implement some NFC protocols in their devices but in a much more programmable way, how does that work? Is the protocol used in credit cards related at all? And how do these relate to Felica, the system used everywhere in Japan (which was in the news for a while because the factory where they made the chips burned down and they had a chip shortage - giving Apple an opening to move into the market with iPhone NFC)?
As far as I can tell, the NFC ecosystem is a mess of competing, incompatible protocols from different companies, as well as incompatibilities for historical reasons.
For example, Clipper uses MIFARE DESFire, which is the more secure sibling of the Ultralight chip that I examined. Washington's SmarTrip cards use MIFARE Plux X. New York City's OMNY, on the other hand, is apparently built on top of the Mastercard payment network using EMV. Montreal's rechargeable OPUS card (not the disposable one I examined) uses the completely different Calypso standard. FeliCa was developed in Japan along a different path and has a different standard (NFC-F vs NFC-A) with different modulation, protocol, and data rates. The NFC chips used in phones try to be compatible with as much as possible. These NFC systems all use the same 13.56 MHz frequency, so the radio hardware is compatible across them.
On it, but I couldn't have said it better :) To expand on Felica vs. ISO a bit:
Theoretically Felica is a different stack from ISO 14443, but it's close enough that it almost got specified as a variant of ISO 14443 as well (C; MIFARE and most other systems use A). NFC does specify Felica as one possible official tag type (then called NFC-F, as opposed to NFC-A and NFC-B), so practically, most mobile devices can just also read it.
For anybody wanting to experiment a bit, I can highly recommend getting any Android device and installing NFC tag reader by NXP; it'll show you what technology exactly a given card uses, and in some cases can show you other interesting information as well. There's also an app that lets you read the current balance of various transit cards.
> Is the protocol used in credit cards related at all?
In e.g. London and the Netherlands, the readers were upgraded to support tapping in and out with a debit/credit card or Apple/Google Pay.
However, Apple also seems to have an ‘Express’ mode, which even works when the battery is empty (‘Power Reserve’).
It seems to me that there must be three protocols: the one for the disposable and stored-value tickets (ISO 14443?), EMV for debit/credit/Apple Pay/Google Pay, and Apple Pay Express.
EMV (specifically EMV contactless) is also based on ISO 14443, it's more like an application layer protocol on top of it.
Apple Pay Express is just Apple Pay without the need for the full system UI: "If iOS isn’t in use because iPhone needs to be charged, there may still be enough power in the battery to support Express Card transactions." it interacts the same way as the physical card equivalent (otherwise they would need a reader upgrade).
Right. Much like the fact Find My functionality can still let you track your phone when it’s “dead”, the power requirements are just so low that when the phone can’t get going due to the requirements of the CPU + RAM + display there’s plenty to power NFC/BT beacon stuff for a while.
An AirTag can operate on a CR2032 for two years. An Energizer datasheet says that’s 235 mAh. An iPhone 13 Mini has a 2438 mAh battery (~10x). It makes sense the phone could do it for at least a day or two with the left over charge.
(I don’t know how long it would actually keep working)
Both EMV and MIFARE (and similar solutions) indeed sit on top of ISO 14443-4 (or -3 for the older/lighter MIFARE versions), but they're conceptually very different:
EMV is an account-based payments protocol, and the card only confirms its presence in a transaction; balances are managed on the backend. The reader does not authenticate itself to the card at all.
MIFARE is a stored-value service and as such keeps track of the card's balance on-chip. This requires another smartcard on the reader side, holding the necessary keys for mutual authentication, but allows two-sided offline transactions, which is quite useful for transit applications (e.g. buses dropping out of network coverage, allowing higher volumes even during short server outages etc.)
> MIFARE is a stored-value service and as such keeps track of the card's balance on-chip. This requires another smartcard on the reader side, holding the necessary keys for mutual authentication, but allows two-sided offline transactions, which is quite useful for transit applications (e.g. buses dropping out of network coverage, allowing higher volumes even during short server outages etc.)
MIFARE cards are used in all kinds of applications and not all of them require the reader to authenticate itself. And even in authenticated uses the keys don't neccessarily need to be stored in a smartcard (SAM) depending on the security requirements. For the simpler MIFARE cards a secure enclave for the keys doesn't even provide any additional security since they key is transmitted to the card anyway - and the simplest ones don't have any authentication at all.
> a secure enclave for the keys doesn't even provide any additional security since they key is transmitted to the card anyway
I'd assume that the keys (more accurately passwords, since a key would never be transmitted to the card over an unencrypted interface) are diversified by card serial number though? In that case, it would still be useful to have an SAM to hold that diversification key. You could further store some MAC authentication tag on the password-protected tag that the SAM needs to see before revealing the password over the radio.
I'm not saying that this is how every transit system practically does use MIFARE Ultralight, but based on the design, it's definitely possible.
Apple and Google achieve the same outcome (i.e. something called "card emulation", where an NFC chip can act as an emulated ISO 14443-4 smartcard), but they achieve it through very different ways:
Google just has an Android API for it called HCE (Host Card Emulation), and anybody can write an app that implements it (i.e. Google Pay has no special position compared to competitors). In a nutshell, you just get a callback for every APDU (protocol message) the phone receives from the reader and get to respond as you wish.
Apple embeds a secure element in their devices, which is a chip almost identical to that you'll find in actual physical cards, but with an additional interface that connects it to the application processor, so that the OS and (privileged, i.e. Apple Wallet only) apps can interface with it and load new card applications. That's why the storage in Apple Wallet is limited to 50-ish cards, but Google Pay allows many more :)
Felica is not part of the ISO 14443 family, but closely related and also an official physical layer of NFC (NFC-F), so many devices practically support it as well. To my knowledge, there is no software-based emulation for it though (that's always a bit risky for stored-value cards), so Suica etc. only work on Japanese phone models that have the necessary secure element, as well as on all iPhones (Apple installs a Felica applet into their secure element on demand).
Is it possible that the Android implementation could be less secure given the lack of a dedicated secure element? Perhaps not, but I am curious why Apple does it that way.
It's definitely less secure for issuers: The entire point of having a secure element is that the issuers of digital wallet cards and passes can't trust all of their users to not decompile their app and extract a private key that grants fraudsters infinite money or transit rides. Physical cards and secure elements on the other hand are resistant against key extraction even in an adversarial environment.
There are ways to mitigate that in software (e.g. by not ever loading long-lived keys into software, fetching them just in time after device attestation etc.), but while that works pretty well for the kind of payments where the terminal needs to be online anyway, it's very risky for offline transactions.
That's why Suica and most other stored-value passes only support iPhones and a handful of specific Android devices that have a secure element (or can use the SIM card as one).
Do you have any insight into the economics of this in general compared to other disposable solutions. Are manufacturing old school magnetic stripe tickets, or just optical scanning/barcodes a lot cheaper?
I imagine magnetic stripes have a higher failure to read rate at the turnstile causing issues, while both them and optical scanning requires the ticket to be inserted into the machine, adding complexity and moving parts.
I couldn't find a nice price breakdown. I'd expect the magnetic stripe tickets to be cheaper to manufacture, but since the NFC tickets cost pennies, there isn't a lot of money to save. I agree with you that magnetic stripes would have a much higher maintenance cost due to the mechanical aspect and the read/write head. Optical scanning seems less likely to work the first time, based on my experience with airplane checkins. NFC is probably the best from an ecosystem perspective since it can work with credit cards and phones as well. NFC readers are probably the cheapest since they are produced in large volumes for credit card point of sale.
I’ve occasionally gotten to watch transit workers open up and service the magnetic stripe card readers in the BART. Those things are complicated. It may well cost less to outright replace a contactless reader module on a fare gate than to service a magnetic stripe ticket machine once. Even an Adafruit PN532 board is only $40.
I've not worked with the Adafruit PN532, but for an extra $10 you can get a Pepper C1 USB from Eccel which is very easy to work with. It is a stand-alone device, so you don't have to connect it to anything but power. Has WiFi & BT built in and has a built-in web server to configure it with, you can have it make calls via REST, MQTT, WebSocket.
Interestingly, the Pepper C1 is essentially a PN518 (presumably a sibling of the PN532 on Adafruit's board) hooked up to an ESP32. So a very simple device - and I've had a project on the backburner which is pretty much a DIY clone of it. If they made a USB-C version I'd ditch mine and buy it in a heartbeat.
BART stopped accepting paper tickets last year, presumably because of the complexity (not just the ticket barriers, but also the fare machines and add value machines that also had to handle them): https://www.bart.gov/news/articles/2023/news20230911
Yeah, they moved to a native integration with Apple/Google/Samsung Wallets, and Clipper cards as a backup (but they really try to discourage them, at least for tourists).
The cool thing is that their thing doesn't work with all Android phones for an unknown reason (various people from the transit agency said "oh Android? Yeah it doesn't always work with Android"), which you have no way of knowing before topping up money and trying to use your phone.
If anyone is curious, it was a Xiaomi Redmi phone, a midrange one that has no issues paying over NFC. A OnePlus next to it with the same Android version worked just fine.
FWIW, Montreal used to have mag strip paper tickets and turnstiles to match, but ever since the new paper tickets rolled out we have new svelte turnstiles with an NFC reader exclusively.
They've been trying to get contactless bank card payments going on the same turnstiles but roll-out has been bogged down by other transit agencies apparently.
I’ve been curious about the orientation of these devices. For examples, if I want to track an item’s presence in a box, would I have to coat the entire item in these chips to get one to be in the right orientation?
I think it depends on the type of antenna. A linearly polarized RFID antenna is sensitive to the tag's orientation, but a circularly polarized antenna is less sensitive to orientation. Systems can also use more than one RFID antenna to get better coverage.
The trick is to use a metallurgical microscope, which shines the light down through the lens. A regular microscope illuminates from below, which works fine for cells, but not for opaque chips.
Specifically, I use an AmScope ME300TZB-2L-10M microscope, which my friends consider an entry-level microscope, but it works for my needs.
Kind of a software question, but why isn't nfc with asymmetric keys a thing? It seems like at best this is a custom javacard app on select expensive cards ($4 per card if you buy 1000 on aliexpress) or $70 for a yubikey otherwise. Is getting the signature time fast enough just impossible with current hardware/tramission power restrictions?
as always a delight to read ken! im curious about speculation how to do the bonding and mounting of these chips at scale. at this size even the general handling and cutting of wafers are hard to imagine for me. how did the connections to the antenna look like and was there an indication of different glue / adhesive layers apart from the coatings you described?
I'm curious about how the unique ID is programmed into each chip. Presumably all the chips on the wafer come out identical - at which point in the process are they individually selected and given a unique personality? Is it done with direct electrical contact that is then fused off, or using the near field link?
It's probably done through normal write commands if there is any explicit lock bit at all (it could doesn't just check if any of the UID bits are already non-zero and then reject the write). You can actually make other parts of the memory read-only too by setting bits at a specified address [0] (which then cannot be unset again).
Since they need to probe each die to test it on the wafer, they set the UID at the same time. According to the datasheet, "These bytes are programmed and write protected in the production test."
> One complication is that the counters have an "anti-tearing" feature for additional security
Two questions:
1. Why is it a "complication"? Is it just that it makes the counters more complicated, or is there something frustrating about the counters?
2. I would love to learn more about how the anti-tearing feature works!
The problem is that if the user tears the card away from the reader in the middle of an update, that card can end up with corrupted data. This makes implementing the increment-only counters more complicated. For instance, the straightforward approach might hold 00 FF in two bytes. If you increment the counter by updating the low-order byte first, but the card gets torn away before you update the high-order byte, you end up with 00 00, and the counter has gone backward.
A simple way of preventing tearing is to have two copies of each counter; if there is tearing, then the two values will be different.
Looking at an NXP patent [1], they use a much more complicated approach, using a level of indirection. They write the new value to a different memory page and then update a pointer to
the new page. There are various progress bits recorded along the way so they can roll back as needed.
Surely they're not using 75µm/120µm wafers throughout the entire production process - that's literally the thickness of a human hair! Can a 200/300mm wafer of that thickness even support itself, let alone all the stresses in the production process?
It isn’t different from other anti-counterfeiting measures, the printing just happens to be really small and electrically react to certain frequencies.
Part of the “software eating the world” story is the decreased cost of precision that enabled the hardware substrate of software to be inexpensively and ubiquitously included in any mass produced object.
All of the waste that went into producing it of course.
IC fabrication produces a lot of chemical waste, and I would imagine that these ICs aren't fabbed in a place that has a great track record on pollution.
These devices are so tiny that presumably this is also a tiny part of IC fabrication.
I'm not saying there is none, just trying get an idea of how much of a problem this really is. We also need to consider what impact any alternative solution would have.
What struck me from the description of the system was that it seems that no electronics is really needed at all, a unique QR or barcode would be just as good because the back end system records the use.
But that would require the installation of optical readers in a system that might not have them but does already have NFC readers. Adding those readers would add a considerable amount of e-waste too.
I don't like the e-waste aspect either, but realistically, the chip is so minuscule that the amount of waste is trivial compared to almost anything else you might discard. The chip is literally the size of a grain of salt.
The other factor is that people who use tickets regularly would use the rechargeable plastic cards, rather than the disposable tickets, so the amount of waste is reduced.
On one hand it is probably small in comparison, but on the other hand, it seems much more feasible to reuse transit ticket ICs than e.g. food packaging.
Many transit agencies do explicitly incentivize reuse, e.g. by offering cheaper fares using a reloadable contactless card and often charging a deposit for that card.
Even then, many of these systems have been struggling due to the IC shortage, given the low margins these single-use tickets have to operate on. In some Asian countries, including Japan and Malaysia, it was tricky to get a new transit card for several months or even years, even though there is a deposit charge.
> ”the chip is so minuscule that the amount of waste is trivial”
It does add significant costs to the transport system. Single-use NFC cards must cost at least a few cents to produce and dispense, which adds up when you’re talking about hundreds of thousands or millions of rides every day.
Even reusable NFC cards are costly in terms of providing all the infrastructure to support them: software, servers, enough top-up machines in stations to handle peak demand, commissions to retailers selling the cards, extra staff to deal with customer support, delays and congestion caused by top-up/ticketing queues, etc.
That’s one reason London’s TfL has been pushing everyone to just use their bank-issued contactless credit/debit cards (or NFC-enabled phones) for years now.
It’s also more convenient, of course, to never have to worry about your balance or recharging the card.
I don’t really see why a chip is needed at all for single use tickets. Those have existed forever and there are a plethora of non-chip options ranging from the simple holepunch to the optical printed barcode or QR code.
Because that would require a completely different way to read tickets than are used for stored value cards. Every ticket machine needs way to print which is less reliable than writing NFC chip. It is likely that printing a ticket costs more than NFC. Every fare reader needs two sensors, one NFC and one optical. The optical ones are going to be slower. People are going to get confused about which reader to use.
But why are you making it worse and more complicated? Disposable NFC card is better, cheaper, and easier to use.
The NFC doesn't need to be printed. It just needs to be dispensed.
My city went from printed paper tickets, that didn't even need to be scanned, to contactless fare system with paper NFC tickets. It saves money having simpler and less used ticket machines. It helps that most people use contactless credit card or fare card. They really should have more signs that can tap phone or credit card cause I suspect tourists think they need to buy ticket.
Magstripes tend to work not so well when you have the ticket in your pocket for a couple days, printed codes involve people futzing with cameras. You can use a sort of card ingestion system to line up a QR code or the like... but those things are complicated and break down a lot! You end up needing staff to constantly be opening it and unclogging it. This works alright if you have like 6 turnstiles, less so when you have 2 or 3.
Obviously you can work with those models anyways, and plenty of transportation networks do! But if your rush hour involves moving a million+ people, you really do need this stuff to go fast.
> Magstripes tend to work not so well when you have the ticket in your pocket for a couple days
How very true... SWIPE CARD AGAIN AT THIS TURNSTILE in glowing turqouise-ish dot matrix letters will be forever etched into my brain long after the Metrocard is finally gone.
I feel like 99% of people would not benefit from single use public transportation tickets. Even if you are a tourist, if you use public transportation once, there is a high likelihood you will use it multiple more times, in which case it makes sense to get a regular card. Most systems let you return the card and get the deposit back if you'd like.
Personally I collect the cards instead because I have a tendency to revisit cities years into the future. I just wish cities wouldn't make their cards expire so damn quickly. Wuhan's metro is nice, the cards don't expire until 10 years later. But I've found Singapore and Taipei expire within 3 years and you lose your stored money.
I have this "brick" of public transit cards for about 20 cities. It feels powerful. I kind of wish I could just swipe this brick in any city and just go. Unfortunately they all interfere with each other.
I don't know how many times I've been in a city for a single day, or part of one, and have zero interest in spending precious minutes finding, buying, and returning a card.
Just let me pay with coins, or a credit card in seconds, with no return work.
I believe Singapore's public transit does support tapping a credit card directly at the gates now, but there's an annoying step of having to register your card in advance on an app before it actually works.
My guess is this might be because on-the-fly credit card authorizations still take too long. Waiting 3 seconds for an EMV contactless verification would seriously hold up the line at rush hour in a country where most people live by public transit.
If I were to guess, the registration is probably what enables them to pre-authorize a credit line and allow you to tap in in a fraction of a second.
Interesting, and this hypothesis shows why twmp cards might be preferred.
I have no issue with temp cards, if I can buy them right at the pickup location. I once flew into a place late at night, and only stores had cards to buy, and all were closed.
Yeah that's a stupid system and I've seen it in many places. Being asked to go to <some random convenience store> to get the official public transit card, even the dude at the station couldn't sell me one.
The vending machines at every station should be capable of directly vending public transit cards. I think most of the better systems around the world do work that way.
That's odd. Most open-loop transit payment systems I know give new/unknown cards the benefit of the doubt, and put the card on a block list if it turns out to not be good for the fare that's eventually distributed to all readers.
Are you sure that's true? Their website says otherwise:
> Do I need to sign up for a SimplyGo account to use my contactless bank card for transit?
You do not need to sign up for a SimplyGo account to use your contactless bank card for transit.
OK, it's confusing, I had seen some other information that suggested app registration was necessary. It seems that it's only necessary if you want to track your journeys which makes sense.
I’m pretty sure that the Montreal paper tickets are non-refillable but can “contain” multiple rides or a pass (weekend, weekly, etc) if you buy them together.
I’d bet a lot of them are sold at the airport: the fare to downtown comes with a 24-hr pass for other buses and metros.
Indeed, I didn’t know what kind of ticket we are talking about - folks please include a picture and some context in your blogs, for people from other places and countries
Photo of the ticket / ticket machine is an obvious thing to include.
Some people live on a different continents and their environment looks completely different. This is giving me same vibes as those ‘probe you are not a robot’ tests that ask you to identify things that are specific to USA’
I've actually always wondered what type of system the Portugese cards use: They don't seem to be based on anything ISO 14443 (or 15693) at least, since they don't react to my phone or external reader at all.
I think this chip is implemented with a state machine rather than a processor, so it's meaningless to compare their processing power. The Apollo Guidance Computer had about 17,000 transistors, while I estimate that the NFC chip has about 45,000 transistors. So the NFC chip has more complexity, but the same order of magnitude.
Same here! It seems like a fascinating system, especially in the federated way in which it's being used by various Japanese transit agencies and issuers. Compared to MIFARE, it was definitely ahead of its time.
Unfortunately, most things I could find are in Japanese, as expected; I suspect that the really interesting parts aren't public, as usual in this industry (there's still a lot of belief in security by obscurity, even if the systems actually don't need it).
Singapore's CEPAS seems very similar conceptually to Felica (at least in application, in that there's multiple issuers of stored-value cards with interoperability), and the specifications for that seem to be available for purchase, but I'm not curious enough to bite that bullet yet :)
It's not really on the technical side of thigns, but the unification of IC cards across transportation companies has a good write up [0] that has a bunch of fun details. My favorite thing is how the people working on the project just had a bunch of card readers from various transport companies all in one room.
One small caveat: As much as I appreciate his writing, I'd take some of the technical explanations with a grain of salt – the approach is definitely more that of an (extremely knowledgeable and experienced!) outsider looking at the system and coming up with hypotheses for its workings than that of an authoritative source with hands-on experience working on the system. It's sometimes not that easy to figure out what's hypothesis and what's "confirmed" knowledge as a result.
That said, much of what I've learned about Japanese transit payment systems (without ever having visited) was via that blog. It's amazing!
Somebody from the tiny intersection of people apparently having hands-on experience with Felica and writing about it in English is this pseudonymous Reddit user (often also quoted on the blog): https://www.reddit.com/user/FelicaDude/
It is using a relatively old manufacturing process. It may be small but it is because modern chips are small, not because this is a feat of engineering where they've achieved incredible compute densities.
Comparing Montreal subway with Vancouver's skytrain:
- Montreals subway stations have this gritty, distinctively french atmosphere i loved it.
- Vancouvers above/below stations have no soul, distinctively anglo but above ground ones i liked.
- Montreal train cars use rubber wheels to my shock! Extremely loud.
- Vancouver train cars use some sort of electric system which im not familiar with ( have a few variants (newer hyundai rotem cars, old ones: https://www.youtube.com/watch?v=W_BoeXqaV9c)
- Montreal subway does not cover the entire region like Vancouver's skytrain. Getting around is difficult without uber. Road conditions are horrible (pot holes remain unfixed for decades, city went broke hosting olympics long time ago), I just shudder how you can get around during the winter.
But the biggest shock was that in some instances, it was faster for me to walk then walk to the station and wait for the subway.
- Arriving at YVR: Skytrain runs directly from airport to a satellite city where its numerous public buses cover almost the entire MV. I could just tap through the toll gate with my credit card and wait for a bus which arrives on time quite frequently.
- Arrriving at YUL: Have to take a bus from airport for 30 minutes to Montreal but doesn't seem to respect time schedule. Got off somewhere in Montreal I don't remember (there was a large open artsy area) tried to wait for a bus but never came, gave up, got uber.
In addition to how hosting the Olympics hurt Montreal financially, there was substantial tax revenue loss from the trend of corporate headquarters moving from Montreal to Toronto staring in the 1960s due to Francophone policies.
Yeah they seem to do this every recession. I don't see any value in forcing French language which btw, people from France laugh and make fun of Quebecois. I've seen it at work too.
Yeah the Montreal area transport system uses the opus system (the disposable cards are part of that) for everything. Sadly, it's now bizarrely more complicated with the weird zones that they recently added after half a decade of consultations that were meant to... stream line intercity travel! for example, if you take the metro in Montreal, then ride it until Laval, you have to buy a specific type of ticket with the two zones.
Meaning that if you just buy the normal ticket in any Montreal station and make the mistake of going to Laval, you can be fined and they do tons of ticket traps because they know that people make that mistake pretty ogten. It's not even a separate line or something. And the same card wouldn't let you take a bus in Laval because again, it's another ticket (but not the same as the one for the dual zone metro that I was talking about earlier...). Just a huge mess when it used to be much simpler before they "streamlined" it.
When I visited Montreal I mostly walked and used their rental bicycle. I did take a few subway rides and being from Vancouver it didn't leave any specific impression on me one way or the other - I got where I needed to get to (some suburb).
The Skytrain to YVR is indeed very nice - built for the winter Olympics. Maybe not as "connected" as some European airports but quite convenient.
The problem with transit in Vancouver is that most of it is rays emanating from downtown, i.e. you have fairly decent (though IMO worse than most large European cities) transit if you need to get downtown but it's terrible useless if you need to get across. My work used to be 20 minutes drive time, >2 hours transit time.
Skytrain doesn't exactly cover the entire region, as you get further away from the downtown core the coverage gets much spottier until when you get far enough (but still part of metro Vancouver) it's non-existent.
There are certainly times when buses don't show up on time. I take transit these days to work and back and I would say something like 30% of the time the bus isn't on time. About 5% of the time the bus I'm supposed to take just never shows up.
clean and soulless >>>>>>>>>> distinct and gritty for public transit
i'm from vancouver, and every day I take the NYC subway i wish it was cleaner and more soulless, more hospital sterility, harsh 6500K lighting, glass and stainless, and less literal grit
On the topic of NFC: my iPhone ApplePay thing taps so much more reliably than any of my credit or debit cards. Is this because it has its own power supply and doesn’t have to first be powered up by the machine?
Additional conjecture: a device with upgradable software can take advantage of updates to readers and protocols. Whereas the physical card is stuck at the version it was created with.
NFC supports passive mode (where one side is powered and the card is not) and active mode (where both sides are powered). So, yes, your phone is probably more reliable because it provides a powered data transmission.
An NFC card doesn't actively transmit data. Instead, it sends data using "load modulation", where it switches a load across the antenna to change how much power it absorbs. The transmitter can detect this change in power, but the signal is extremely weak (80 decibels below the transmitted signal), so it's amazing that it works at all.
The iPhone doesn't actually use NFC's peer-to-peer/"active" mode (since contactless payments aren't an NFC application; see my other comments on that), but it does specifically include an NFC "field amplifier" IC (shown in some iFixit teardowns), which most other smartphones and of course all physical cards/tags lack.
This does mean that iPhones can't do cool tricks like booting up the secure element purely from the field with a completely dead battery though that some earlier Android and Windows Phones could do (or at least Apple has intentionally deactivated that capability for a more consistent/secure experience) :)
The primary reason is probably just that the secure element in more recent iPhones is probably just an order of magnitude more beefy than the IC in your physical cards.
Powering up the IC actually doesn't take long, but the processing itself can: Contactless payment transactions (mostly) use asymmetric cryptography, and old one at that too (usually RSA), so simply crunching the numbers takes these fairly underpowered ICs quite some time, even when they include cryptographic coprocessors.
Compare that with (symmetric key based) transit ticket authentication, e.g. for MIFARE DESfire or Japanese Felica cards: These usually use DES or AES, which is lightning fast in comparison.
This is fascinating. We were just in Europe where we experienced these tickets for the first time. I had trouble with them; I was trying to figure out how to scan them because it never occurred to me that they might contain an NFC chip.
My wife, on the other hand, who is not at all technical, took it for granted that you would tap them and immediately figured it out intuitively.
Thunder Bay, Ontario. Pop. 110k. We still have the sort of carnival-style paper tickets. I would guess that most smaller cities don’t have fancy NFC tickets.
For small cities a bus is better than a subway. There is no traffic so a bus moves fast enough, and roads don't cost that much. You need those roads anyway for trucks, so may as well reuse them. When a city grows close to a million they should start installing metros - but cities have plenty of warning and so should start reserving space for the metro at 500k.
That's funny - I'm sure I would have shared your confusion, as all tappable objects in my world are made of plastic. I wonder how your wife thought of it?
Probably a mix of plastic and metal: Full metal cards don’t actually support contactless interfaces!
Two common ways of getting around that is to either sandwich a plastic part containing the antenna to a metal one, or to punch out a circular part in the middle of the metal card and put the antenna in there (and close it all up using more plastic).
One card that doesn’t do either is the Apple Card – and as a result, you can’t tap it!
> Probably a mix of plastic and metal: Full metal cards don’t actually support contactless interfaces!
Well it's really annoying: the "metal" card (maybe as you say a mix of metal and plastic) is harder to swipe, so I got use to present it face down instead of face up, for I noticed that that way I get a better percentage of success on the first try.
I don't have the problem with my full plastic credit/debit cards.
Yeah, the sandwich-type cards usually have one preferred side for contactless taps. That's one advantage of the cutout-style cards, I suppose, but I haven't seen many of these lately.
Probably because it's around the size of a credit card and has fake smart card contacts printed on it. That being said, I would probably get confused myself too.
The ones in Athens are thin white cards and as such easy to see the aerial through it. Additionally there's no slot to put it through, and a big tap surface at each gate with the RFID logo with someone tapping a card on it.[1] I think it would be hard to miss for anyone familiar with the concept of tapping cards.
I have found the same thing with my wife. I'm a technical person, but I'm extremely bad with tools and such, including the ticket thing. If no one shows me how to use it I'll probably figure out a way to insert it somewhere. My wife won't have any problem with this and other small tools.
The same thing with IKEA: I always rely on the manual and just blindly follow the instructions, and gets very frustrated if the instructions miss one step.
> The same thing with IKEA: I always rely on the manual and just blindly follow the instructions, and gets very frustrated if the instructions miss one step.
Following instructions is a good thing. Plenty of people damage stuff when putting it together since it looks obvious, but they usually miss critical details. I would imagine that the people who designed the card scanners had to put a lot of thought into their design simply because they know many people won't read instructions and would do as you suggest: figure out a way to insert [the card] somewhere.
For things like IKEA furniture there often is a good engineering reason to do things in a specific order that is not obvious. For furniture this is okay - nobody does it often (or if you do it is a few things that you memorize the instructions for).
Transit has different considerations though. It is critical that doing the right thing is obvious without reading instructions. Someone might have an important meeting to make and the time to read the instructions (or wait for the person in from of them to read the instructions) means they are late. Or (worse?!?) that time spent in line is annoying enough that someone decides to buy a car. You can somewhat get around this with more fare machines - but they are expensive and take up a lot of space. Fortunately we have human-machine interaction specialists who can tell you how to make a fare machine that is easy to use correctly without needing any instructions.
> The same thing with IKEA: I always rely on the manual and just blindly follow the instructions, and gets very frustrated if the instructions miss one step.
Thing I figured out assembling IKEA stuff in the past few years: if it seems like they skipped a step, look carefully at the details in pictures. Perhaps use a magnifying glass. There's going to be only one way to get from step N to step N+1, and all the information to figure it out is there. The drawings of all the pieces, from major parts to tiniest of screws, have accurate details, and there's enough of them to disambiguate the situation.
You really do need a magnifying glass for some of those details, as the (asymmetrical) holes that ID which way some part must go become dots at the scale they print some of the manuals. You're absolutely right though: all the info is there, just got to work it out
Ikea also doesn't use Philips screws. They have pozidriv screws and need pozidriv bits if you dont want to strip the screw heads. I learned the hard way.
"I always rely on the manual and just blindly follow the instructions, and gets very frustrated if the instructions miss one step"
But why do people make incomplete manuals? If I have a step by step guidance and it doesn't work, because some steps were left out, than this is just a wrong manual!
Typically this means they stepped the design and didn't bother to revise the doc, or used up the stock of manuals for the old version before starting on the new ones.
Because most companies view the manual as an afterthought. You've already bought it. What are you going to do if the manual is bad, return it? And even then, you're returning it to a third-party store - the manufacturer isn't going to care care. You bought an ShelfExpress for 50% off at Furniture Mart, can you really expect them to care?
Ikea, on the other hand, prides itself on user experience. Everything is Ikea-branded, so any complaint will come back to Ikea because the buck stops there. Everything is sold internationally, and they don't want to translate it into a dozen languages, so they have to make clear assembly diagrams. Their entire brand is built around having great assembly instructions!
Some instruction booklets are completely BS. I recently tried out a Coleman 8-people tent and the booklet is just a 4-picture page. The official setup video on YouTube is less than 2 minutes...
I mean, it's completely useless for people who has zero experience with camping -- exactly the people who need those instructions and videos and exactly the people who buy these types of tents from Costco.
Basically all other flat pack furniture I’ve ever bought has, but none of the dozen or so ikea items I’ve assembled. It’s part of why I only buy flat pack if it’s ikea, now.
I recently assembled two non-IKEA flat-packed items from two different vendors.
One left out details in the diagrams in each step that they had deemed irrelevant to that step. This apparent attempt at simplifying the instructions stumped me for ages because I kept thinking I'd oriented pieces wrong due to the number of holes in the picture differing from the number of holes in the physical thing.
The other had switched some parts since the instructions were made, and hadn't bothered to update the instructions. This was a bit more obvious, but still kinda irritating for someone like me who is uncomfortable with uncertainty when I believe certainty should be attainable.
Whatever else can be said of IKEA, their manuals and quality control are excellent. I think of them as the McDonald's of furniture — it's never the best product, but it's damn good for the price, and you know exactly what you're going to get.
No, the card doesn't have any symbols like that. It does have a pictogram of the card getting tapped on a reader, along with the text "Apposez sur le lecteur".
Most metro stations have a much simpler way for travellers to figure out what to do: of loads people who do know how it works, ahead of and beside you.
It's getting better but, in my experience, once metro systems got away from manned booths and tokens, the systems worked fine for commuters but led to lots of fumbling and long lines for tourists.
Trains in the UK still have a certain amount of "Which of these tickets/receipts go where?" while a line of irritated locals is building up behind you. Fortunately, also being the UK, someone will help you if you're struggling with something sooner rather than later.
Not really. My last trip to the UK I ended up--because of a complicated trip--with more of a bag than I should really have had on public transit. I was actually a bit embarrassed but a few folks were super-helpful with tube stations that were, shall we say, not exactly mobility friendly.
I'm not a Londoner, but I am British, and so feel qualified to say that you don't need to feel embarrassed :) I've travelled with over 100L of luggage on the Tube before - it's my contribution to the trains' traction!
“Make the damn train work” is not a local custom. Aside from that the UK rail system is so complicated and expensive you’d expect a manned gate at every station at the least.
£150 from London to Leeds?! I can fly halfway across Europe for less…
£165.90, to be precise (anytime single). Or, if you travel late-morning to early-afternoon, £70.20 (super off-peak single). By booking weeks or months in advance, you can travel for as little as £22.50 (advance single).
The unofficial BR Fares[1] website does a lot to untangle the complexity, although it can only do so much to mitigate the expense.
Making purchases ahead varies quite a bit across Europe. The UK seems to fall pretty hard on the you really should buy well in advance side or you're going to pay through the nose.
I used to work with someone who, even on an expense account, would roll their eyes if someone wanted them to do a last minute trip to London.
Indeed! Travelling last-minute, you could even be 'quids in' by popping over to the continent for an afternoon so that you'd be eligible for an Interrail ticket:
Nearly fifty pounds less than the price of two Leeds <-> London Anytime Single fares, £331.80! And since hotel rooms in London aren't cheap either, you might even save money by staying the night in Lille rather than London. Kings Cross is part of the same station complex as the Eurostar departures at St. Pancras, so you would save money, spend less than three additional hours travelling and not even risk getting rained on.
This is Hacker News, but even still, I feel kind of icky suggesting a 500-kilometre detour to save money on a journey between two British cities no further than that distance from each other. How I wish we could just have a British version of the Austrian 'climate ticket' and leave all of our inscrutable rail fares behind us!
I’m used to traveling the same distance for around £40 regardless of the time I book (shinkansen).
I guess it’s too bad I can’t save money on booking in advance, but on the other hand, I can easily jump on the train at any point of the day without sticker shock.
I always read up on how the local transit system works when I visit a new place. But that’s never adequately prepared me to smoothly use a public bus like a local would the very first time.
Some transit systems are just inherently more confusing than others. It doesn’t matter to the locals who know the quirks, but that doesn’t mean something can’t be improved. NYC has a great subway system, but I find the signage and general wayfinding quite lacking. Tokyo’s system is on a similar level of complexity but has excellent wayfinding and is generally much easier for a tourist to use.
Poor UI is poor UI. Recently visited system which supports contactless payment. So the terminal is there. And it has arrow to left with logo of contactless payment. Logically first thought is that you just swipe card from right to left over it right? No keeps failing, is something wrong with my card? Also other card does not work...
In the end assholes designing it hid the payment terminal in such way that you can't see it from usual angle of use.. Amazingly hostile user design for those that rarely use that transport system...
I recently visited Paris. I read up and watched videos on how to use the metro. They didn't really cover many of the important local customs: I let people off the train before trying to cram in and I held the exit gates open on my way out of a station so they didn't slam in the next person's face. I must have stuck out as a tourist. The "act like a local" public info available is never sufficient.
I'm into transit and so I did my best to understand the system last time I went someplace - and it still took me a few minutes to figure out what I needed to do last time I went to a new city. And the tourists who didn't think to look this up in front of me took even longer. Nothing was hard, but when you don't know exactly what you need it takes some time to figure that out.
The above assumes you know you will be there and so can look things up. I wasn't planning to leave the airport in one city so I didn't look up what locals do - then weather made me miss the connection and I was stuck in a city for a day.
Locals going to a new part of their own city often have the same problems trying to read the map and time tables. They are faster than tourists, but still need extra time because they don't know what is going on.
The logo you mention (four arcs actually) is owned by EMVco though, and they let people only use it for credit and debit card contactless payment cards.
There’s also an NFC logo, but as mentioned elsewhere, these cards aren’t really NFC cards, so that would also not be the right thing to use (I believe the NFC forum wants something to happen when you touch anything bearing that logo with your phone).
My guess would be that they used plastic chip cards before (those often also do NFC) and only switched to the paper cards later - at which point they either deliberately copied the whole design including the chip contacts to make the switch as unnoticeable as possible or just lost or couldn't be bothered to find the original design files and scanned an existing card for the print template.
All Moscow public transport powered by these chips (actually it was, nowadays the chips we use are clones, made in Russia itself) - trains, metro and buses.
For a few years now, you may usually do a contactless card payment - just tap your bank (debit or credit) card. The fare is often higher but so is convenience.
Back around 2010 I remember reading these accusations that significant part of revenue went directly to Mifare for the massive number of chips.
And for single rides, some of Metro systems still use these steampunk brass tokens. Sometimes, less authentic plastic.
In the systems I’ve ridden, there’s usually some kind of plastic stored-value card for regular riders, and the (more expensive) disposable tickets are only used by occasional riders.
> Presumably, the makers thought that making the card look like a smart card would help people understand it. The card actually uses an entirely different technology.
It’s kind of the same, though. The physical communication layer is different, but the higher protocol layers are basically identical. Smart cards with contacts follow ISO 7816. These MIFARE contactless cards are ISO 14443 Type A cards, and their protocol follows ISO 7816-4.
This shouldn’t be terribly surprising — the entire ecosystem built for smart cards with contacts wants to support contactless cards with minimal changes, and this includes the host software, the readers, and the logic in the cards. There are even plenty of devices where the same device supports contact and contactless uses — plenty of credit cards, bank cards, and FIDO devices are like this.
This is analogous to WiFi and wired Ethernet. They’re have very different physical layers, but they are logically compatible, and the same software supports both.
Only ISO 14443-4 uses the same protocol as ISO 7816 (another way of saying this is that ISO 14443-4 represents the higher layers of ISO 7816 over a different physical interface), though.
MIFARE Ultralight does not actually implement 14443-4/7816/"smartcard"-style APDUs; it's significantly simpler, since the ICs are much less powerful.
To make things more confusing, some MIFARE ICs really do implement ISO 14443-4 (e.g. their fixed-function MIFARE DESfire cards, and their programmable smartcard ICs like SmartMX), but not all of them.
One of my claims to fame was being part of the team that built the first online banking site for a bank in my country around 1997.
One of the things you could do was pay certain types of widely used paper invoices. When I was brought on, the UI for this was just a standard HTML table with labels and input boxes. I decided to build a prototype with a paper invoice image as the background and a textboxes places where the numbers appearred on the paper invoice.
When people paid the invoice, they would have the paper version they had received by postal mail next to them. Now, their mission was to enter the numbers so they would end up with a visual one-to-one copy of the paper invoice on the computer screen. It made it easy for everyone to figure out which numbers to enter.
People embraced this immediately, and all forms were changed to follow this principle. All banks implemented it in their banking apps and still use it today.
Around the same time (2001) I worked for a startup that was doing the same thing but with Flash instead of HTML. We were building European export forms. People really liked the UI side of it.
In my country we used to have a heavily standardized type of money transfer card. It'd be used both for regular wire transfers in a "fixed payer, flexible payee" form where you'd get a booklet of them to fill out later, and "flexible payer, fixed payee" form you'd get mailed to your house to pay your bills, only having to write your account number on them, sign it, and mail it to your bank.
They were designed to be machine-readable from the start for easy processing at the bank, and one of the ways they did this was by having all the fixed data encoded in a special font. When we started using smartphone banking apps, you'd just be able to scan a bill with your phone and it'd immediately read out all the data, fill in the missing stuff, and you'd only have to tap "confirm" to do the actual payment.
> There are multiple NFC standards with differences in speed, protocol, and range, including NFC-A, NFC-B, NFC-C, NFC-F, and NFC-V. The MIFARE Ultralight cards use NFC-A, which is defined by the standard "ISO/IEC 14443 Type A".
Pet peeve: Calling these chips "NFC" is a bit misleading. NFC-A isn't defined by ISO 14443-A, but builds on it.
NFC is an umbrella standard that defines a way of storing structured data on a wide variety of existing contactless IC technologies (including, but not limited to ISO 14443) and products (such as NXP's various MIFARE chips, which in turn are based on various layers of ISO 14443 up to -4).
For the concrete example, it's correct to say that one possible implementation of an NFC-A tag is MIFARE Ultralight (that would be a NFC forum type 2 tag), but neither is NFC the only thing you can do with MIFARE Ultralight (and this transit use case almost certainly doesn't put an NDEF container on the ticket), nor is this the only type of tag you could use for NFC.
Except that the highest layers in that stack is not used by many contactless systems. As an analogy, you wouldn't call HTTP or TCP "web protocols" either, even though the web uses both (but it can also run on QUIC, which is UDP, and you can do non-web-things via HTTP).
Importantly, NFC standardizes a way of storing structured data like URLs or phone numbers on NFC tags; transit tickets most likely don't use tags in that way.
> The Ultralight chip has a few features beyond a printed ticket, though. The chips are manufactured with a unique 7-byte identification code (UID). Moreover, the UID is signed, ensuring that fake UIDs cannot be generated.
The problem is, they can be just as easily cloned. Your average Flipper Zero can do that.
If you want actual security, you have to go for a challenge-response scheme - i.e. every card is provisioned at the factory with a unique private / public key pair, and the public key gets signed by the factory. Then, to verify authenticity, the terminal gives some random nonce, the card signs it using its private key, and the terminal verifies that against the factory's public key.
> Even so, there were a couple of times that I lost track of the chip and had to check some specks under the microscope to determine which was the chip and which were dirt.
That is the really amazing part for me. We as humans have difficulty handling them, but how on earth does a machine even manufacture these, much less orient them consistently for the bond process to work?!
> The problem is, they can be just as easily cloned.
Not if the validation system uses the password feature of MIFARE Ultralight. For single-use tickets, which are invalidated immediately after being read, this can be good enough and is much more lightweight on the IC side.
It's utterly not worth it. Your time to get it working, the equipment... but even if you have all of those if you get caught they will throw the book on you to scare away others. You can be charged by Unauthorized use of computer, Fraud and who knows what else. All of that to save four dollars on a ticket? When every station has cameras?
> Like what, there's Tiktoks advising young dumbasses precisely what they need to steal and joyride cars.
Yeah, because cars are valuable and joyriding a stolen car is impressive and cool to lots of teens. Getting a free ride on the bus is like negative street cred.
> If you want actual security, you have to go for a challenge-response scheme
Another option is to just store used UIDs in a database. In fact, you could do a system with only UIDs. For a single use ticket, validate the UID signature and mark it as spent the first time it is used, then every use after that will be denied.
A card can be cloned, and it will work, once, it means one could steal a ticket by walking by and using appropriate equipment (not just a Flipper Zero as it is too short ranged) and use it before the legitimate owner does. I don't think it is something to worry about for a single use subway ticket.
To improve security for multi-use tickets, one could use rolling codes: every time a ticket is scanned and its UID validated, some code is read from the NFC memory and it has to match a sequence, the next code is then written back to memory and has to be provided next time, invalidating any clone. Tickets can still be stolen, but you can't beat the system unless you crack the server-side encryption.
More valuable tickets like commuter passes can use a different system with a challenge-response scheme.
This scheme implies a low-latency, high-availability connection to a backend database. That's not easy to achieve in many transit system environments, hence the relative popularity of systems with some level of distribution.
Practical systems often are online these days, but only use that connection for eventual consistency style reconciliation.
> A card can be cloned, and it will work, once, it means one could steal a ticket by walking by and using appropriate equipment (not just a Flipper Zero as it is too short ranged) and use it before the legitimate owner does.
Even MIFARE Ultralight supports a basic password authentication scheme, where only legitimate readers know (or can derive) that password, so there a bit better protected against cloning than pure passive storage cards.
> If you want actual security, you have to go for a challenge-response scheme
Sure you just have to accept that you're now vulnerable to Denial of Service attacks, or just DoS due to unrelated service infrastructure outages caused by things like backhoes.
> much less orient them consistently for the bond process to work?!
It's not all that consistent. They have a 3% failure rate. And you have to accept a unique map of "broken chips" with every single order you receive.
> The problem is, they can be just as easily cloned
But you can only clone a ticket who's ID you use. So you can buy a ticket and clone it, but what have you achieved? It is still validated "on the backend" once you use either the first time.
So the only real risk is that you clone a random person's ticket between them buying it and using it which is a security flaw, but probably a very minor issue in real-world use.
Maybe there could be slight issue with day passes? You could buy a single day pass then issue clones at a lower price. However it is likely not an issue worth paying for more expensive chips to avoid.
You can use these around the house or car for location-tap automation. Tap on NFC tag and mobile phone can trigger a custom shortcut for local action or SSH script to Linux SBC or micro PC. Response time is about one second. Even the iPhone SE2 has an NFC reader.
For vision-impaired people, NFC tags can be attached to objects and the phone can read an audio description when the object is tapped against phone.
Around that time, I recall there being a lot of hype around RFID tags. E.g. the Touchatag was just a bunch of RFID tags and a USB RFID reader, but marketed as a consumer product. This never really seems to have caught on, though.
Nowadays, I suppose most consumers do have RFID tags (debit cards, transport cards, building keys, e-Passports), they just might not be aware of the underlying technology.
All the patents and "sekhurity" isn't helping. A decade ago, I ended up with a bunch of programmable NFC stickers that my Galaxy S7 suddenly wasn't able to read, because some MIFARE intellectual property issue retroactively bricked this class of NFC stickers. Good luck figuring out where on the compatibility matrix the Amazon listing you're looking at is.
MIFARE (classic) tags were never really compliant with any industry standard (whether freely available or patent-encumbered) and are not actually NFC tags, so many systems betting on that but later wanting to e.g. change reader chip vendors ended up with issues such as this. (There's a way of writing NFC/NDEF-formatted data to them, but it's only readable by NXP chips.)
If you buy any standard NFC forum tag, chances are pretty good that it'll work with any Android or iOS device. The Ntag series has worked pretty well for me on both OSes and across various phones; I have one that instantly and cross-platform rickrolls everybody tapping it.
Given that these things are essentially QR codes via another medium, I'm not surprised that it never caught on: QR codes are much cheaper to make (it costs nothing to include them on a leaflet other than some extra ink/toner!) and basically serve the same purpose.
Where they make more sense is when they actually include dynamic information: Some of the newer tags can e.g. include an authentication tag in the URL part, which lets you verify the tag's authenticity (together with a web service that keeps track with the high watermark of opened sequence numbers).
I wouldn't call that "RFID" anymore, though; to me, RFID means transmitting only an identifier, with all the logic happening on the backend, but ISO 14443 tags get most interesting/useful when they go beyond that and do things like authentication or local processing.
Makes me get out of bed and tap my phone on a specific NFC tag placed somewhere around the house, in order to turn off the alarm. Then, I may as well wake up, since I'm already out of bed : )
It's a nice companion to help perform 'habit stacking' as Atomic Habits calls it. Want to do pushups right after waking up? Place an NFC card under your workout mat, so you're forced to the mat first thing in the morning.
Fair. My mother used to put one of those old rattling alarm clocks with two bells on top into a metallic dish and placed that combo at the other end of the room. Similar concept.
Not a huge advantage, but I'd say mostly range and flexibility. You may want to put the tag farther away than you could hear an alarm clock, if you want to go to another room. And you could customize the alarm so you're guided towards a different tag every day of the week, without needing multiple (or any) alarm clocks.
I use "alarm clock xtreme" on Android that is similar; it has math and "type these random characters" puzzle as well as snooze detection so you hit "I'm awake" but also includes snoozing/stopping via number of steps detected or by scanning a barcode etc. Definitely recommend it.
But even so, I wish it would force me to key in the current time to disable, that way my sleepy brain would better understand "it's time to wake up now, because it is x time".
I saw an NFC chip that has 512 bytes of eeprom. Talks to a micro via I2C and has an interrupt that can be used to wake it up.
I think it's a M24LR04E.
Costs like $0.50.
I think these could be useful for devices where you have a limited amount of data you want to read or transfer. Like why have bluetooth and all the crap that entails when all you want to do is configure a device once.
Advantage of a separate IC is you can use it with whatever microcontroller development stack you have working.
The problem is that it is simply a dual-interface EEPROM. It only holds data, it doesn't process it. Great for something like a device whose configuration you can update via NFC tap (think e-paper display), not so great if you want to do a whole challenge-response dance between microcontroller and NFC smartphone.
This is interesting but clearly not intended for security/cryptographic applications... no security hardening, no hardware cryptography, and it's also not available in a card form factor according to the datasheet.
It's manufactured pretty much the same as any other chip, using photolithography. Most of the analog components would be CMOS transistors, just larger. They might use a BiCMOS process with a few extra steps to make bipolar transistors. And there might be an extra step for the capacitors. But overall, the chip uses an old, simple manufacturing process, much easier than cutting-edge processors.
The chip seems like it's almost too small? I don't even know how they would cut up the wafer and how they would pick each die and mount it in the paper card.
They cut the wafer apart with a diamond blade, 20 µm thick. Laser cutters can make thinner cuts, but they cost more. Die pick-and-place machines can manipulate even smaller dies at high speed: https://www.syagrussystems.com/dts-2-die-sorter
They are going away soon (TM), the tech is cool but they are impractical. I will be happy to use my credit card or phone.
Too many times I have been stuck in 15-20 minutes queues to buy those tickets and you cant refill them with an app... Plus south shore and north shore have they own system it's a mess.
But you can still purchase these one-time use cards with cash? That’s the case with my local transit system. Are there places that are eliminating cash altogether?
In NYC, there will soon be no more single ride tickets.
There’s the OMNY card, and I believe the original plan was to outsource sales and top-ups to third-party stores, but lately I’ve also seen some vending machines for that in some stations, so maybe they’re going back a bit on that idea.
It is theoretically possible to refill it with the phone. You either have a stored value card where the value is stored on the card and have the phone's NFC talk to it, or you store the value in a server that has an API to add value and have the reader at the subway deduct the value from the server.
I think Oyster cards are still stored-value based, but I suspect that either the backend servers and connections are now fast enough to poll pending top-ups in real time, or they just fan out the pending top up dataset to all turnstiles.
I remember using that feature in the SF bay area, and while it took a day for the top-up to actually propagate to all readers, it even worked on buses, so they must be uploading that data everywhere.
That type of connection needs to be there in any system that supports lost/stolen card value recovery, in any case, since that's how card block lists are distributed.
TfL likely need that mechanism primarily to synchronize the list of blocked open-loop bank cards with unpaid balances to all readers. Faster Oyster transaction list updates and any-station remote top-ups are probably just a side effect of that.
Clipper doesn't (yet) support open-loop bank cards yet, so for them, it's probably enough to update more remote readers every time the bus goes back to the depot, for example.
Yeah they added refills but you can't use your phone as an NFC pass yet :(. I've always been curious to know more about why, you'd think if you can refill your Opus card with your phone, to then use it on the terminal, you could just skip the card step entirely but I'm sure it's not that simple!
They're actively working on allowing you to just use your phone, iirc targeted for like 2026 or something. Basically, its' a work in progress and they delivered the update to the Chrono app as a stop-gap.
I agree in that they are much more convenient for tourists and occasional users, but when living in a city and taking public transit every day, I actually prefer stored-value cards, as there are still some advantages that arguably make them a better fit for the transit use case:
- Full offline support (i.e. both the reader and payment device don't need network connectivity), making the system more resilient
- Symmetric cryptography and highly optimized transaction flow, making reads more reliable and allowing faster customer flows through transit gates
- Upfront transparency about charges, monthly passes, capping etc. – you immediately see your balance left after tapping.
- No "transaction spam". This is more on my specific transit provider (NYC MTA), but I'm really not a fan of getting an individual credit card charge for every. single. tap. It can't be cheap in terms of fees for the operator either! At least other systems, like TfL in London, aggregate taps over a day, but it's still not great.
Singapore's public transit agency recently attempted to switch from a stored value based model to an exclusively account based one, but had to backpedal quickly due to public outrage about the move.
Ideally, a system supports both payment methods: Open-loop payment cards for infrequent users, and stored-value cards (both physical and in digital wallets) for heavy users and anybody else that prefers them. But realistically, maintaining both is too much of a burden for many transit agencies.
> I agree in that they are much more convenient for tourists and occasional users […]
I would argue that contactless debit/credit card or mobile wallet taps are substantially more convenient for tourists and occasional users – if you are fresh off the boat (or off the plane – for a more modern twist), not much can beat the convenience of turning up at the turnstile, tapping on and getting on with the trip on the local public transport network and tapping off at the end of the trip.
No need to look for a place that sells local rechargeable or disposable NFC cards, having to be aware of a low balance, looking for a place where the card can be topped up, actually top them up and stuff like that. For frequent travellers, it also entails having fewer non-portable mass transit payment cards to carry.
Bonus points: debit/credit card/mobile wallet payments also eliminate the problem of the discovery and consolidation of lost balances when a card gets lost, and it reduces the environment impact (manufacturing + energy consumed during the process) and the wastage (the disposal or, rather, the lack thereof) that disposable NFC cards inherently possess.
That is what Sydney (the one that is not in Canada) has done: they went straight from prepaid paper tickets to their own rechargeable Octopus/Oyster style cards (with the name also beginning with an «O» – Opal) followed by enabling debit/credit card (Visa/MC/AmEx) and mobile wallet NFC payments later within the larger metropolitan area public transport network on buses, ferries, trains and trams.
Convenience, as always and of course, comes at the expense of privacy, though.
Yeah, that's what I meant, sorry if that wasn't clear – open-loop payment card based systems make more sense for infrequent users and tourists for all the reasons you've mentioned; dedicated card purse-based systems can be better for regular commuters.
> […] dedicated card purse-based systems can be better for regular commuters.
I suppose it is a matter of personal or circumstantial preferences so I won't go into that, but through reading this discussion, I have learned that, e.g. the Boston MTBA's CharlieCard, have an expiry date and has to be replaced in person. From the regular commuter's point of view it is a nuisance of epic proportions – to turn up at a bus stop or a station only to find out they are unable to pay because their dedicated card has expired. The commuter is only interested in the act of paying the fare and not in complexities of the local mass transit system's payment network shenanigans.
I also can't help noticing that the wallet (the purse style) making business has taken a hit in recent years due to the rapidly decreasing circulation of cash and the rise of mobile wallets. Many people now leave their homes with their smartphones and keys only. Eventually and inevitably, all cities will embrace either the integration with or adoption of mobile wallets, but that will take a while depending on how well each government funds its local public transport agency.
Mobile wallets are not a contradiction to dedicated transit cards, though!
Apple Wallet supports transit cards for dozens of transit systems, and most of them have some associated app to allow managing monthly passes or topping up the balance. Arguably, that's the best of both worlds.
Yes, I am in a full agreement on the best of both worlds, with a couple of caveats.
Apple Wallet supports neither the Montreal (the subject of this discussion) nor Boston CharlieCard transit cards nor many more. Apple Wallet has promptly shown some transit cards from mainland China, 1x from France, 1x from Hong Kong, 3x from Japan and only 3x (!) from the US (Clipper, SmarTrip and TAP). That is all it supports. Android may support more.
The said CharlieCard[0] supports a bespoke mTicket app that is neither integrated with the mobile wallet nor fully supports all modes of transportation in Boston:
√ Best for Commuter Rail and ferry riders who don’t often take the subway or bus
∅ No transfers to other modes
Which brings me to the main caveat. Compared to debit/credit card payments originated in a mobile wallet, supporting each transit card in existence is an extra effort that places the onus at least on the vendor of the mobile operating system and usually on the local government as well. Generally, governments do not have a good track record at delivering modern digital solutions to their citizens and are inefficient at engaging the smartphone vendors. So at the very least, the governments are slow to instigate a technological change.
And, since the onus is also on the government to upgrade NFC readers across the entire network anyway – to support modern ways of paying, the question is which one is more future proof: 1) natively supporting a local transit card at the smartphone level + upgrade the NFC readers to support a variety of NFC protocols, or 2) upgrade the NFC readers to support the debit/credit card and mobile wallet payments only? I am inclined to think that (2) is more efficient and more cost-effective for taxpayers.
Definitely – the challenges and cost of maintaining these individual systems should not be underestimated.
But practically, a lot of them are run by a small set of contractors anyway, not any government entity directly. These only need to integrate with wallet providers once; beyond that it's just a matter of contract terms and uploading a few new assets to Apple's and Google's servers. (I believe Apple can even launch new transit cards without an iOS update these days.)
Montreal has mostly followed this trajectory, be we haven't yet stuck the landing yet on bank cards. Most turnstiles now are equipped to handle them but the project has stalled a bit.
That still seems expensive for a $3.75 metro fare.
2.4% of the cost of your ride is the chip in the ticket itself? Maybe it's worth it because it lets them eliminate mechanical ticket-reading and unify paper tickets with other NFC payment methods.
These single use tickets are used essentially only by tourists and those who use public transport only on occasion.
The vast majority of users will use rechargeable Opus cards [1] that can contain a variety of different fare types (single tickets, monthly tickets, etc).
From an operator's point of view it definitely makes sense to only have to maintain one type of reader, even if that means losing a few cents profit on the low single digit percent of rides that use the disposable tickets.
I assume all regular customers will be paying a fare of $3.25 or less per ride on the reusable Opus card (fare purchased in a 10-ride pack). Essentially you’re paying for the chip with the very-occasional-commuter one-ride convenience fee.
Mifare is what’s been used in London’s Oyster cards for 20 years (not the ultralight ones mind), and Hong Kong for even longer.
However oyster really is in its way out for most uses. contactless and especially a phone is far more convenient for non season use, and far less wasteful.
costco already has this for ID cards in the states (and I've also seen it for account ID for home depot and some other places where it's tied to discounts). the app will pull up an ID card with a QR code that changes every 60 seconds or so to prevent screenshotting and trivial reuse, which is analogous to the function the chip performs in terms of challenge-authentication.
There's a noticeable delay between contactless cards and oysters. Some people I know prefer oyster cards simply because they open the gates faster, in spite of having to top them off all the time.
I'm looking forward to not having to choose one trade-off over the other.
It’s noticeable if you’re used to the instant response of Oyster, but we’re talking about a few hundred extra milliseconds. Not something that bothers you once you’re accustomed to it.
It’s still fast enough that it will read my Apple Watch before the gate starts to close from the passenger in front of me.
One saved trip to an Oyster top-up machine will make up for a lifetime of contactless NFC latency!
> ”Is it not possible to top up a digital Oyster card on an iPhone or Apple Watch via an app or Apple Wallet?”
It is, there’s even an auto top-up option that adds credit automatically if your balance drops below a certain level.
But there’s no “digital” Oyster card, only physical ones. If you want to use a device to pay you have to use contactless.
And either way, it’s still kind of a pain to have to maintain a balance - especially if you’re a tourist or visitor and don’t know exactly how much credit you’re going to need.
I agree that being able to load a transit card into Apple Pay etc is also a good solution. The convenience of not having a physical card that can be easily lost or forgotten is probably the biggest benefit for me.
At peak hours it can definitely be a problem, you really need the entire pipeline to work well. There's going to be somebody behind you most of the time, and you really don't want people stuck at the gates.
In Japan credit card transactions routinely take a couple seconds. Imagine each person taking 5 seconds to go through the gate! I think what trials for credit card payments in transportation services there are doing is simply not processing the transaction inline, and just doing it after the fact (assuming it will go through).
Yes, the TfL system does a partial authorisation. It checks the card is valid and not blocked etc but doesn’t necessarily do a real-time authorisation all the way to the issuing bank.
If you try to use a card that is valid but has no available balance/credit, it might work for the first ride but then be blocked when you try to use it for the return trip.
Fares are batched throughout the day and you are charged once, overnight, for all rides that day (after applying any multi-ride discounts, etc).
This is different from some other cities where I’ve used contactless payments and they’d charge you immediately for each ride, giving you lots of annoying little charges on your bank statement!
Wonder how they block the card, my impression was that tokenization was meant to make it harder for card chargers to be able to track a card through multiple taps like that.
TfL not only gets your Apple Pay device account number (DAN), but can also associate it with the primary card number (PAN). Both magically appear if you add the primary card to your online TfL account and have used the associated Apple Pay device with TfL before.
>but we’re talking about a few hundred extra milliseconds. Not something that bothers you once you’re accustomed to it.
Wrong. With the traffic volumes normally seen in Tokyo, those few hundred extra milliseconds will cause huge delays at the fare gates. There's a reason the systems here use the Felica card which processes in 100ms: it's really needed for this kind of pedestrian volume.
The MIFARE protocol (which Oyster cards use) takes 300ms to 500ms per tap. EMV (i.e. contactless cards) take ~500ms, which slows down normal walking speed.
I think there are plans for contactless smartphone tickets in Montreal too. I wonder why they haven't done that yet, it's been years since they've started talking about it.
Hong Kong's Octopus card uses Felica, as far as I know.
It's conceptually very similar to MIFARE – a fixed function IC implementing a fully offline stored value purse – but uses a stack that differs from ISO 14443 A on pretty much all layers. (It was planned to possibly become ISO 14443 C, but that never happened.)
>Hong Kong's Octopus card uses Felica, as far as I know.
Yes: Felica was developed by Sony in Japan, but was actually first adopted in Hong Kong, then later in Japan. It's far better than other standards, because it's so fast.
Isn't Mifare in different forms a de-facto standard for NFC subway tickets around the world? St Petersburg uses Mifare Classic (and tokens), Moscow also uses Mifare Classic for the refillable Troika card and Mifare Ultralight for disposable ones, Dubai "nol" card is a Mifare Desfire, Los Angeles "tap" card is a Mifare Classic, and, yes, the London Oyster is a Mifare Desfire EV1. Yes I actually went through my stack of transit cards and scanned those of them that I wasn't sure about.
The only ones that I came across that are not Mifare, and not even readable by Android (but readable by the Flipper Zero), are the paper tickets used in Brussels. Then, of course, there are non-NFC tickets. For example those that use magnetic stripes, like the cute tiny ones in Paris or NYC's MetroCard.
Japan uses FeliCa for its integrated transport cards (I just read an Osaka Metro ICOCA card with NFC Tools to check). This is used by quite a few systems around the world, including Hong Kong's Octopus.
That's a lot more MIFARE Classic than I would have expected considering that reader support for those is a lot less guaranteed these days. I guess a lot of them might be legacy systems.
There are two distinct types of Oyster card, but I don't know which is which, other than from a user perspective. All I know is that I had an old style one (the one without the white D in a blue square on the back) and you could still use it, you just couldn't "connect it" to the app so you couldn't look up your travel history.
There was a complicated process for returning it and getting a replacement, but as they'd already phased in paying by bank card by then, and the only advantage of an oyster card was for season tickets, I just returned it and got my deposit back.
But if you're into collecting different card types, you might want to try to get hold of one of these old ones as well. They're probably somewhat rare now, as they were encouraging people to upgrade to the new ones at least 5 years ago.
The article says the chips are made on a 180 nm process and they come out about the size of a table salt grain.
We’re now down in the single digits for fabrication in nanometers, although I know that sort of just a name. This chip is so tiny already, if you were to fab it on a process like 7 nm I’m guessing it would be unworkably small. Too hard to cut, too hard to manipulate individual chips once you did manage to cut them.
So here’s my question: how small can we make a chip in area while still being able to cut them out and easily use them?
It’s obviously not a concern for the hundreds of square millimeters of a large processor, but I’ve never heard about the opposite end of the spectrum before.
There are a few issues. First, you lose 20 µm due to the saw cut between the dies. I saw an NXP patent that said this was wasting 30% of the die for their tiny chips. If you made the chips smaller, you'd be wasting even more. Another issue is that you need some area for the bond pads, so you can't make your chips arbitrarily small or they will be useless.
Looking at a random die pick-and-place machine [1], it handles dies down to 0.2mm in either dimension. So you could handle smaller dies than mine with an off-the-shelf machine, but not a lot smaller.
Phosphoric acid, hydrochloric acid, and boiling sulfuric acid: I should have paid more attention in chemistry lab. This is a neat project and answered a lot of questions.
It's not as scary as it sounds :-) For a chip this small, I only need a few drops of chemical, which cuts the risk way down. I don't have beakers full of hydrofluoric acid and red fuming nitric acid, like the real decappers.
524 comments
[ 4.1 ms ] story [ 307 ms ] threadWhat is the actual mechanism behind the DESFire and other secure NFC chips that prevents cloning?
The DESFire and other secure chips contain a cryptographic key that you can't access. Without the key, you can't make a clone of the chip. The cryptography provides authentication and encryption that you don't get with the cheap Ultralight chip.
I think this is all market segmentation; they don't put more security into the Ultralight chip because they don't want to cannibalize their higher-end sales.
Ultralight C does support actual cryptographic authentication.
Also, many of these transit systems are eventually consistent (they're usually offline-capable for resilience, but usually manage to send all validation transactions to a backoffice system within at most a day, and often minutes).
This allows detecting duplicate usage fairly quickly. In systems where you need to tap out as well as tap in to leave the turnstile, that's where ticket inspectors might take a sudden interest in you if you tap out with a cloned ticket.
In the end, as with most security systems, the goal is not to make fraud absolutely impossible, but to make it economically non-viable.
I can't think of a much worse way to do security. That feels like trying to flood the market with lockpicks that don't work instead of making a more pick-resistant lock.
There are single-use fares as well, the "CharlieTicket" that you might've encountered.
More CharlieCard NFC info:
https://medium.com/@bobbyrsec/operation-charlie-hacking-the-...
https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20pre...
I found myself in Paris having to cross the other day and forgot how terrible the old way of buying tickets was, amazed that it’s still the norm in so many cities
You can also store only an ID in a QR code, but you could also fit more information and a digital signature of it in there.
And sure, simply using the serial number might pose a security risk depending on the application, but that rarely stops implementors to implement such schemes. More often than not do people believe in security by obscurity, sigh. For a simply ticket system the serial number should be secure enought as it is a use-once application.
MIFARE Ultralight C and larger/more expensive chips allow challenge-response authentication, making them pratically uncloneable. These are usually used for reloadable and monthly passes.
How does this fit into the broader NFC ecosystem? What do other big metro systems like Omny, Clipper, Smartrip etc use? Apple and Google seem to implement some NFC protocols in their devices but in a much more programmable way, how does that work? Is the protocol used in credit cards related at all? And how do these relate to Felica, the system used everywhere in Japan (which was in the news for a while because the factory where they made the chips burned down and they had a chip shortage - giving Apple an opening to move into the market with iPhone NFC)?
As far as I can tell, the NFC ecosystem is a mess of competing, incompatible protocols from different companies, as well as incompatibilities for historical reasons. For example, Clipper uses MIFARE DESFire, which is the more secure sibling of the Ultralight chip that I examined. Washington's SmarTrip cards use MIFARE Plux X. New York City's OMNY, on the other hand, is apparently built on top of the Mastercard payment network using EMV. Montreal's rechargeable OPUS card (not the disposable one I examined) uses the completely different Calypso standard. FeliCa was developed in Japan along a different path and has a different standard (NFC-F vs NFC-A) with different modulation, protocol, and data rates. The NFC chips used in phones try to be compatible with as much as possible. These NFC systems all use the same 13.56 MHz frequency, so the radio hardware is compatible across them.
Theoretically Felica is a different stack from ISO 14443, but it's close enough that it almost got specified as a variant of ISO 14443 as well (C; MIFARE and most other systems use A). NFC does specify Felica as one possible official tag type (then called NFC-F, as opposed to NFC-A and NFC-B), so practically, most mobile devices can just also read it.
For anybody wanting to experiment a bit, I can highly recommend getting any Android device and installing NFC tag reader by NXP; it'll show you what technology exactly a given card uses, and in some cases can show you other interesting information as well. There's also an app that lets you read the current balance of various transit cards.
In e.g. London and the Netherlands, the readers were upgraded to support tapping in and out with a debit/credit card or Apple/Google Pay.
However, Apple also seems to have an ‘Express’ mode, which even works when the battery is empty (‘Power Reserve’).
It seems to me that there must be three protocols: the one for the disposable and stored-value tickets (ISO 14443?), EMV for debit/credit/Apple Pay/Google Pay, and Apple Pay Express.
Apple Pay Express is just Apple Pay without the need for the full system UI: "If iOS isn’t in use because iPhone needs to be charged, there may still be enough power in the battery to support Express Card transactions." it interacts the same way as the physical card equivalent (otherwise they would need a reader upgrade).
An AirTag can operate on a CR2032 for two years. An Energizer datasheet says that’s 235 mAh. An iPhone 13 Mini has a 2438 mAh battery (~10x). It makes sense the phone could do it for at least a day or two with the left over charge.
(I don’t know how long it would actually keep working)
EMV is an account-based payments protocol, and the card only confirms its presence in a transaction; balances are managed on the backend. The reader does not authenticate itself to the card at all.
MIFARE is a stored-value service and as such keeps track of the card's balance on-chip. This requires another smartcard on the reader side, holding the necessary keys for mutual authentication, but allows two-sided offline transactions, which is quite useful for transit applications (e.g. buses dropping out of network coverage, allowing higher volumes even during short server outages etc.)
MIFARE cards are used in all kinds of applications and not all of them require the reader to authenticate itself. And even in authenticated uses the keys don't neccessarily need to be stored in a smartcard (SAM) depending on the security requirements. For the simpler MIFARE cards a secure enclave for the keys doesn't even provide any additional security since they key is transmitted to the card anyway - and the simplest ones don't have any authentication at all.
I'd assume that the keys (more accurately passwords, since a key would never be transmitted to the card over an unencrypted interface) are diversified by card serial number though? In that case, it would still be useful to have an SAM to hold that diversification key. You could further store some MAC authentication tag on the password-protected tag that the SAM needs to see before revealing the password over the radio.
I'm not saying that this is how every transit system practically does use MIFARE Ultralight, but based on the design, it's definitely possible.
Google just has an Android API for it called HCE (Host Card Emulation), and anybody can write an app that implements it (i.e. Google Pay has no special position compared to competitors). In a nutshell, you just get a callback for every APDU (protocol message) the phone receives from the reader and get to respond as you wish.
Apple embeds a secure element in their devices, which is a chip almost identical to that you'll find in actual physical cards, but with an additional interface that connects it to the application processor, so that the OS and (privileged, i.e. Apple Wallet only) apps can interface with it and load new card applications. That's why the storage in Apple Wallet is limited to 50-ish cards, but Google Pay allows many more :)
Felica is not part of the ISO 14443 family, but closely related and also an official physical layer of NFC (NFC-F), so many devices practically support it as well. To my knowledge, there is no software-based emulation for it though (that's always a bit risky for stored-value cards), so Suica etc. only work on Japanese phone models that have the necessary secure element, as well as on all iPhones (Apple installs a Felica applet into their secure element on demand).
There are ways to mitigate that in software (e.g. by not ever loading long-lived keys into software, fetching them just in time after device attestation etc.), but while that works pretty well for the kind of payments where the terminal needs to be online anyway, it's very risky for offline transactions.
That's why Suica and most other stored-value passes only support iPhones and a handful of specific Android devices that have a secure element (or can use the SIM card as one).
Do you have any insight into the economics of this in general compared to other disposable solutions. Are manufacturing old school magnetic stripe tickets, or just optical scanning/barcodes a lot cheaper?
I imagine magnetic stripes have a higher failure to read rate at the turnstile causing issues, while both them and optical scanning requires the ticket to be inserted into the machine, adding complexity and moving parts.
The cool thing is that their thing doesn't work with all Android phones for an unknown reason (various people from the transit agency said "oh Android? Yeah it doesn't always work with Android"), which you have no way of knowing before topping up money and trying to use your phone.
If anyone is curious, it was a Xiaomi Redmi phone, a midrange one that has no issues paying over NFC. A OnePlus next to it with the same Android version worked just fine.
They've been trying to get contactless bank card payments going on the same turnstiles but roll-out has been bogged down by other transit agencies apparently.
Specifically, I use an AmScope ME300TZB-2L-10M microscope, which my friends consider an entry-level microscope, but it works for my needs.
I imagine those can use even simpler chips that are completely read-only over the air and only have a UID programmed.
[0] https://www.nxp.com/docs/en/data-sheet/MF0ICU1.pdf#G4008599
In the footnotes you said:
> One complication is that the counters have an "anti-tearing" feature for additional security
Two questions:
1. Why is it a "complication"? Is it just that it makes the counters more complicated, or is there something frustrating about the counters? 2. I would love to learn more about how the anti-tearing feature works!
A simple way of preventing tearing is to have two copies of each counter; if there is tearing, then the two values will be different.
Looking at an NXP patent [1], they use a much more complicated approach, using a level of indirection. They write the new value to a different memory page and then update a pointer to the new page. There are various progress bits recorded along the way so they can roll back as needed.
[1]: https://patents.google.com/patent/EP3226141A1
Here's an article describing an attack on the anti-tearing feature: https://blog.quarkslab.com/rfid-monotonic-counter-anti-teari...
Surely they're not using 75µm/120µm wafers throughout the entire production process - that's literally the thickness of a human hair! Can a 200/300mm wafer of that thickness even support itself, let alone all the stresses in the production process?
Neat stuff, though I can’t say I love the concept of e-waste NFC.
Part of the “software eating the world” story is the decreased cost of precision that enabled the hardware substrate of software to be inexpensively and ubiquitously included in any mass produced object.
IC fabrication produces a lot of chemical waste, and I would imagine that these ICs aren't fabbed in a place that has a great track record on pollution.
I'm not saying there is none, just trying get an idea of how much of a problem this really is. We also need to consider what impact any alternative solution would have.
What struck me from the description of the system was that it seems that no electronics is really needed at all, a unique QR or barcode would be just as good because the back end system records the use.
But that would require the installation of optical readers in a system that might not have them but does already have NFC readers. Adding those readers would add a considerable amount of e-waste too.
The other factor is that people who use tickets regularly would use the rechargeable plastic cards, rather than the disposable tickets, so the amount of waste is reduced.
Many transit agencies do explicitly incentivize reuse, e.g. by offering cheaper fares using a reloadable contactless card and often charging a deposit for that card.
Even then, many of these systems have been struggling due to the IC shortage, given the low margins these single-use tickets have to operate on. In some Asian countries, including Japan and Malaysia, it was tricky to get a new transit card for several months or even years, even though there is a deposit charge.
It does add significant costs to the transport system. Single-use NFC cards must cost at least a few cents to produce and dispense, which adds up when you’re talking about hundreds of thousands or millions of rides every day.
Even reusable NFC cards are costly in terms of providing all the infrastructure to support them: software, servers, enough top-up machines in stations to handle peak demand, commissions to retailers selling the cards, extra staff to deal with customer support, delays and congestion caused by top-up/ticketing queues, etc.
That’s one reason London’s TfL has been pushing everyone to just use their bank-issued contactless credit/debit cards (or NFC-enabled phones) for years now.
It’s also more convenient, of course, to never have to worry about your balance or recharging the card.
Unfortunately the days where you could ride the buses for free around the whole Heathrow area are gone, however.
A ticket needs to be printed anyways, the single use ticket with chip does not come from thin air.
The NFC doesn't need to be printed. It just needs to be dispensed.
My city went from printed paper tickets, that didn't even need to be scanned, to contactless fare system with paper NFC tickets. It saves money having simpler and less used ticket machines. It helps that most people use contactless credit card or fare card. They really should have more signs that can tap phone or credit card cause I suspect tourists think they need to buy ticket.
Magstripes tend to work not so well when you have the ticket in your pocket for a couple days, printed codes involve people futzing with cameras. You can use a sort of card ingestion system to line up a QR code or the like... but those things are complicated and break down a lot! You end up needing staff to constantly be opening it and unclogging it. This works alright if you have like 6 turnstiles, less so when you have 2 or 3.
Obviously you can work with those models anyways, and plenty of transportation networks do! But if your rush hour involves moving a million+ people, you really do need this stuff to go fast.
How very true... SWIPE CARD AGAIN AT THIS TURNSTILE in glowing turqouise-ish dot matrix letters will be forever etched into my brain long after the Metrocard is finally gone.
Personally I collect the cards instead because I have a tendency to revisit cities years into the future. I just wish cities wouldn't make their cards expire so damn quickly. Wuhan's metro is nice, the cards don't expire until 10 years later. But I've found Singapore and Taipei expire within 3 years and you lose your stored money.
I have this "brick" of public transit cards for about 20 cities. It feels powerful. I kind of wish I could just swipe this brick in any city and just go. Unfortunately they all interfere with each other.
Just let me pay with coins, or a credit card in seconds, with no return work.
My guess is this might be because on-the-fly credit card authorizations still take too long. Waiting 3 seconds for an EMV contactless verification would seriously hold up the line at rush hour in a country where most people live by public transit.
If I were to guess, the registration is probably what enables them to pre-authorize a credit line and allow you to tap in in a fraction of a second.
I have no issue with temp cards, if I can buy them right at the pickup location. I once flew into a place late at night, and only stores had cards to buy, and all were closed.
Duh.
The vending machines at every station should be capable of directly vending public transit cards. I think most of the better systems around the world do work that way.
London has been using contactless for a while.
Are you sure that's true? Their website says otherwise:
> Do I need to sign up for a SimplyGo account to use my contactless bank card for transit? You do not need to sign up for a SimplyGo account to use your contactless bank card for transit.
Did this change recently? I travelled a little over a year ago and my Wise card worked right after I landed at the Singapore airport.
I’d bet a lot of them are sold at the airport: the fare to downtown comes with a 24-hr pass for other buses and metros.
Ticket in english sometimes refers to a season or monthly ticket, so it’s pretty ambiguous.
Some people live on a different continents and their environment looks completely different. This is giving me same vibes as those ‘probe you are not a robot’ tests that ask you to identify things that are specific to USA’
In Portugal, you pay extra for the initial ticket, but subsequent uses are cheaper, because you are using the same physical ticket.
Unfortunately, most things I could find are in Japanese, as expected; I suspect that the really interesting parts aren't public, as usual in this industry (there's still a lot of belief in security by obscurity, even if the systems actually don't need it).
Singapore's CEPAS seems very similar conceptually to Felica (at least in application, in that there's multiple issuers of stored-value cards with interoperability), and the specifications for that seem to be available for purchase, but I'm not curious enough to bite that bullet yet :)
[0] https://www.ejrcf.or.jp/jrtr/jrtr62/pdf/6-15_web.pdf
The author understands Japanese sources and writes about how the various Felica-based systems operate and evolve.
One small caveat: As much as I appreciate his writing, I'd take some of the technical explanations with a grain of salt – the approach is definitely more that of an (extremely knowledgeable and experienced!) outsider looking at the system and coming up with hypotheses for its workings than that of an authoritative source with hands-on experience working on the system. It's sometimes not that easy to figure out what's hypothesis and what's "confirmed" knowledge as a result.
That said, much of what I've learned about Japanese transit payment systems (without ever having visited) was via that blog. It's amazing!
Somebody from the tiny intersection of people apparently having hands-on experience with Felica and writing about it in English is this pseudonymous Reddit user (often also quoted on the blog): https://www.reddit.com/user/FelicaDude/
- Montreals subway stations have this gritty, distinctively french atmosphere i loved it.
- Vancouvers above/below stations have no soul, distinctively anglo but above ground ones i liked.
- Montreal train cars use rubber wheels to my shock! Extremely loud.
- Vancouver train cars use some sort of electric system which im not familiar with ( have a few variants (newer hyundai rotem cars, old ones: https://www.youtube.com/watch?v=W_BoeXqaV9c)
- Montreal subway does not cover the entire region like Vancouver's skytrain. Getting around is difficult without uber. Road conditions are horrible (pot holes remain unfixed for decades, city went broke hosting olympics long time ago), I just shudder how you can get around during the winter.
But the biggest shock was that in some instances, it was faster for me to walk then walk to the station and wait for the subway.
- Arriving at YVR: Skytrain runs directly from airport to a satellite city where its numerous public buses cover almost the entire MV. I could just tap through the toll gate with my credit card and wait for a bus which arrives on time quite frequently.
- Arrriving at YUL: Have to take a bus from airport for 30 minutes to Montreal but doesn't seem to respect time schedule. Got off somewhere in Montreal I don't remember (there was a large open artsy area) tried to wait for a bus but never came, gave up, got uber.
It's not supposed to. The new REM train network (a few stations already in use) will cover the region. By 2027. Maybe.
REM will also go to YUL.
PS. Fun fact, REM is also driver-less just like the Skytrain.
Meaning that if you just buy the normal ticket in any Montreal station and make the mistake of going to Laval, you can be fined and they do tons of ticket traps because they know that people make that mistake pretty ogten. It's not even a separate line or something. And the same card wouldn't let you take a bus in Laval because again, it's another ticket (but not the same as the one for the dual zone metro that I was talking about earlier...). Just a huge mess when it used to be much simpler before they "streamlined" it.
The Skytrain to YVR is indeed very nice - built for the winter Olympics. Maybe not as "connected" as some European airports but quite convenient.
The problem with transit in Vancouver is that most of it is rays emanating from downtown, i.e. you have fairly decent (though IMO worse than most large European cities) transit if you need to get downtown but it's terrible useless if you need to get across. My work used to be 20 minutes drive time, >2 hours transit time.
Skytrain doesn't exactly cover the entire region, as you get further away from the downtown core the coverage gets much spottier until when you get far enough (but still part of metro Vancouver) it's non-existent.
There are certainly times when buses don't show up on time. I take transit these days to work and back and I would say something like 30% of the time the bus isn't on time. About 5% of the time the bus I'm supposed to take just never shows up.
i'm from vancouver, and every day I take the NYC subway i wish it was cleaner and more soulless, more hospital sterility, harsh 6500K lighting, glass and stainless, and less literal grit
An NFC card doesn't actively transmit data. Instead, it sends data using "load modulation", where it switches a load across the antenna to change how much power it absorbs. The transmitter can detect this change in power, but the signal is extremely weak (80 decibels below the transmitted signal), so it's amazing that it works at all.
This does mean that iPhones can't do cool tricks like booting up the secure element purely from the field with a completely dead battery though that some earlier Android and Windows Phones could do (or at least Apple has intentionally deactivated that capability for a more consistent/secure experience) :)
Powering up the IC actually doesn't take long, but the processing itself can: Contactless payment transactions (mostly) use asymmetric cryptography, and old one at that too (usually RSA), so simply crunching the numbers takes these fairly underpowered ICs quite some time, even when they include cryptographic coprocessors.
Compare that with (symmetric key based) transit ticket authentication, e.g. for MIFARE DESfire or Japanese Felica cards: These usually use DES or AES, which is lightning fast in comparison.
My wife, on the other hand, who is not at all technical, took it for granted that you would tap them and immediately figured it out intuitively.
yup in mine plastic and metal but not paper.
Two common ways of getting around that is to either sandwich a plastic part containing the antenna to a metal one, or to punch out a circular part in the middle of the metal card and put the antenna in there (and close it all up using more plastic).
One card that doesn’t do either is the Apple Card – and as a result, you can’t tap it!
Well it's really annoying: the "metal" card (maybe as you say a mix of metal and plastic) is harder to swipe, so I got use to present it face down instead of face up, for I noticed that that way I get a better percentage of success on the first try.
I don't have the problem with my full plastic credit/debit cards.
Probably because it's around the size of a credit card and has fake smart card contacts printed on it. That being said, I would probably get confused myself too.
[1] https://www.athenstransport.com/english/tickets/
The same thing with IKEA: I always rely on the manual and just blindly follow the instructions, and gets very frustrated if the instructions miss one step.
Following instructions is a good thing. Plenty of people damage stuff when putting it together since it looks obvious, but they usually miss critical details. I would imagine that the people who designed the card scanners had to put a lot of thought into their design simply because they know many people won't read instructions and would do as you suggest: figure out a way to insert [the card] somewhere.
Transit has different considerations though. It is critical that doing the right thing is obvious without reading instructions. Someone might have an important meeting to make and the time to read the instructions (or wait for the person in from of them to read the instructions) means they are late. Or (worse?!?) that time spent in line is annoying enough that someone decides to buy a car. You can somewhat get around this with more fare machines - but they are expensive and take up a lot of space. Fortunately we have human-machine interaction specialists who can tell you how to make a fare machine that is easy to use correctly without needing any instructions.
Thing I figured out assembling IKEA stuff in the past few years: if it seems like they skipped a step, look carefully at the details in pictures. Perhaps use a magnifying glass. There's going to be only one way to get from step N to step N+1, and all the information to figure it out is there. The drawings of all the pieces, from major parts to tiniest of screws, have accurate details, and there's enough of them to disambiguate the situation.
But why do people make incomplete manuals? If I have a step by step guidance and it doesn't work, because some steps were left out, than this is just a wrong manual!
(I share your frustration)
Ikea, on the other hand, prides itself on user experience. Everything is Ikea-branded, so any complaint will come back to Ikea because the buck stops there. Everything is sold internationally, and they don't want to translate it into a dozen languages, so they have to make clear assembly diagrams. Their entire brand is built around having great assembly instructions!
I mean, it's completely useless for people who has zero experience with camping -- exactly the people who need those instructions and videos and exactly the people who buy these types of tents from Costco.
Basically all other flat pack furniture I’ve ever bought has, but none of the dozen or so ikea items I’ve assembled. It’s part of why I only buy flat pack if it’s ikea, now.
One left out details in the diagrams in each step that they had deemed irrelevant to that step. This apparent attempt at simplifying the instructions stumped me for ages because I kept thinking I'd oriented pieces wrong due to the number of holes in the picture differing from the number of holes in the physical thing.
The other had switched some parts since the instructions were made, and hadn't bothered to update the instructions. This was a bit more obvious, but still kinda irritating for someone like me who is uncomfortable with uncertainty when I believe certainty should be attainable.
Whatever else can be said of IKEA, their manuals and quality control are excellent. I think of them as the McDonald's of furniture — it's never the best product, but it's damn good for the price, and you know exactly what you're going to get.
Trains in the UK still have a certain amount of "Which of these tickets/receipts go where?" while a line of irritated locals is building up behind you. Fortunately, also being the UK, someone will help you if you're struggling with something sooner rather than later.
£150 from London to Leeds?! I can fly halfway across Europe for less…
The unofficial BR Fares[1] website does a lot to untangle the complexity, although it can only do so much to mitigate the expense.
[1]: https://www.brfares.com/
I used to work with someone who, even on an expense account, would roll their eyes if someone wanted them to do a last minute trip to London.
This is Hacker News, but even still, I feel kind of icky suggesting a 500-kilometre detour to save money on a journey between two British cities no further than that distance from each other. How I wish we could just have a British version of the Austrian 'climate ticket' and leave all of our inscrutable rail fares behind us!
I guess it’s too bad I can’t save money on booking in advance, but on the other hand, I can easily jump on the train at any point of the day without sticker shock.
Some transit systems are just inherently more confusing than others. It doesn’t matter to the locals who know the quirks, but that doesn’t mean something can’t be improved. NYC has a great subway system, but I find the signage and general wayfinding quite lacking. Tokyo’s system is on a similar level of complexity but has excellent wayfinding and is generally much easier for a tourist to use.
In the end assholes designing it hid the payment terminal in such way that you can't see it from usual angle of use.. Amazingly hostile user design for those that rarely use that transport system...
The above assumes you know you will be there and so can look things up. I wasn't planning to leave the airport in one city so I didn't look up what locals do - then weather made me miss the connection and I was stuck in a city for a day.
Locals going to a new part of their own city often have the same problems trying to read the map and time tables. They are faster than tourists, but still need extra time because they don't know what is going on.
The logo you mention (four arcs actually) is owned by EMVco though, and they let people only use it for credit and debit card contactless payment cards.
There’s also an NFC logo, but as mentioned elsewhere, these cards aren’t really NFC cards, so that would also not be the right thing to use (I believe the NFC forum wants something to happen when you touch anything bearing that logo with your phone).
Back around 2010 I remember reading these accusations that significant part of revenue went directly to Mifare for the massive number of chips.
And for single rides, some of Metro systems still use these steampunk brass tokens. Sometimes, less authentic plastic.
and every transportation system that pretends to run as a profit center and not a cost center also makes ton of money for the vendors.
It’s kind of the same, though. The physical communication layer is different, but the higher protocol layers are basically identical. Smart cards with contacts follow ISO 7816. These MIFARE contactless cards are ISO 14443 Type A cards, and their protocol follows ISO 7816-4.
This shouldn’t be terribly surprising — the entire ecosystem built for smart cards with contacts wants to support contactless cards with minimal changes, and this includes the host software, the readers, and the logic in the cards. There are even plenty of devices where the same device supports contact and contactless uses — plenty of credit cards, bank cards, and FIDO devices are like this.
This is analogous to WiFi and wired Ethernet. They’re have very different physical layers, but they are logically compatible, and the same software supports both.
MIFARE Ultralight does not actually implement 14443-4/7816/"smartcard"-style APDUs; it's significantly simpler, since the ICs are much less powerful.
To make things more confusing, some MIFARE ICs really do implement ISO 14443-4 (e.g. their fixed-function MIFARE DESfire cards, and their programmable smartcard ICs like SmartMX), but not all of them.
https://www.truecable.com/products/cat6a-field-term-plug-shi...
At that price point, there should be a wifi module hidden in it somewhere :)
[1]: https://blog.benjojo.co.uk/post/smart-sfp-linux-inside [2]: https://shop.hak5.org/products/omg-cable
One of the things you could do was pay certain types of widely used paper invoices. When I was brought on, the UI for this was just a standard HTML table with labels and input boxes. I decided to build a prototype with a paper invoice image as the background and a textboxes places where the numbers appearred on the paper invoice.
When people paid the invoice, they would have the paper version they had received by postal mail next to them. Now, their mission was to enter the numbers so they would end up with a visual one-to-one copy of the paper invoice on the computer screen. It made it easy for everyone to figure out which numbers to enter.
People embraced this immediately, and all forms were changed to follow this principle. All banks implemented it in their banking apps and still use it today.
They were designed to be machine-readable from the start for easy processing at the bank, and one of the ways they did this was by having all the fixed data encoded in a special font. When we started using smartphone banking apps, you'd just be able to scan a bill with your phone and it'd immediately read out all the data, fill in the missing stuff, and you'd only have to tap "confirm" to do the actual payment.
Pet peeve: Calling these chips "NFC" is a bit misleading. NFC-A isn't defined by ISO 14443-A, but builds on it.
NFC is an umbrella standard that defines a way of storing structured data on a wide variety of existing contactless IC technologies (including, but not limited to ISO 14443) and products (such as NXP's various MIFARE chips, which in turn are based on various layers of ISO 14443 up to -4).
For the concrete example, it's correct to say that one possible implementation of an NFC-A tag is MIFARE Ultralight (that would be a NFC forum type 2 tag), but neither is NFC the only thing you can do with MIFARE Ultralight (and this transit use case almost certainly doesn't put an NDEF container on the ticket), nor is this the only type of tag you could use for NFC.
Yeah, then it's appropriate to call this NFC.
Importantly, NFC standardizes a way of storing structured data like URLs or phone numbers on NFC tags; transit tickets most likely don't use tags in that way.
The problem is, they can be just as easily cloned. Your average Flipper Zero can do that.
If you want actual security, you have to go for a challenge-response scheme - i.e. every card is provisioned at the factory with a unique private / public key pair, and the public key gets signed by the factory. Then, to verify authenticity, the terminal gives some random nonce, the card signs it using its private key, and the terminal verifies that against the factory's public key.
> Even so, there were a couple of times that I lost track of the chip and had to check some specks under the microscope to determine which was the chip and which were dirt.
That is the really amazing part for me. We as humans have difficulty handling them, but how on earth does a machine even manufacture these, much less orient them consistently for the bond process to work?!
Not if the validation system uses the password feature of MIFARE Ultralight. For single-use tickets, which are invalidated immediately after being read, this can be good enough and is much more lightweight on the IC side.
Like what, there's Tiktoks advising young dumbasses precisely what they need to steal and joyride cars.
Yeah, because cars are valuable and joyriding a stolen car is impressive and cool to lots of teens. Getting a free ride on the bus is like negative street cred.
Another option is to just store used UIDs in a database. In fact, you could do a system with only UIDs. For a single use ticket, validate the UID signature and mark it as spent the first time it is used, then every use after that will be denied.
A card can be cloned, and it will work, once, it means one could steal a ticket by walking by and using appropriate equipment (not just a Flipper Zero as it is too short ranged) and use it before the legitimate owner does. I don't think it is something to worry about for a single use subway ticket.
To improve security for multi-use tickets, one could use rolling codes: every time a ticket is scanned and its UID validated, some code is read from the NFC memory and it has to match a sequence, the next code is then written back to memory and has to be provided next time, invalidating any clone. Tickets can still be stolen, but you can't beat the system unless you crack the server-side encryption.
More valuable tickets like commuter passes can use a different system with a challenge-response scheme.
Practical systems often are online these days, but only use that connection for eventual consistency style reconciliation.
> A card can be cloned, and it will work, once, it means one could steal a ticket by walking by and using appropriate equipment (not just a Flipper Zero as it is too short ranged) and use it before the legitimate owner does.
Even MIFARE Ultralight supports a basic password authentication scheme, where only legitimate readers know (or can derive) that password, so there a bit better protected against cloning than pure passive storage cards.
Sure you just have to accept that you're now vulnerable to Denial of Service attacks, or just DoS due to unrelated service infrastructure outages caused by things like backhoes.
> much less orient them consistently for the bond process to work?!
It's not all that consistent. They have a 3% failure rate. And you have to accept a unique map of "broken chips" with every single order you receive.
But you can only clone a ticket who's ID you use. So you can buy a ticket and clone it, but what have you achieved? It is still validated "on the backend" once you use either the first time.
So the only real risk is that you clone a random person's ticket between them buying it and using it which is a security flaw, but probably a very minor issue in real-world use.
Maybe there could be slight issue with day passes? You could buy a single day pass then issue clones at a lower price. However it is likely not an issue worth paying for more expensive chips to avoid.
Ha ha ha ha... Love it! Always informative and interesting :)
For vision-impaired people, NFC tags can be attached to objects and the phone can read an audio description when the object is tapped against phone.
Nowadays, I suppose most consumers do have RFID tags (debit cards, transport cards, building keys, e-Passports), they just might not be aware of the underlying technology.
This vendor has an array of RFID products: https://gototags.com
If you buy any standard NFC forum tag, chances are pretty good that it'll work with any Android or iOS device. The Ntag series has worked pretty well for me on both OSes and across various phones; I have one that instantly and cross-platform rickrolls everybody tapping it.
Where they make more sense is when they actually include dynamic information: Some of the newer tags can e.g. include an authentication tag in the URL part, which lets you verify the tag's authenticity (together with a web service that keeps track with the high watermark of opened sequence numbers).
I wouldn't call that "RFID" anymore, though; to me, RFID means transmitting only an identifier, with all the logic happening on the backend, but ISO 14443 tags get most interesting/useful when they go beyond that and do things like authentication or local processing.
Makes me get out of bed and tap my phone on a specific NFC tag placed somewhere around the house, in order to turn off the alarm. Then, I may as well wake up, since I'm already out of bed : )
It's a nice companion to help perform 'habit stacking' as Atomic Habits calls it. Want to do pushups right after waking up? Place an NFC card under your workout mat, so you're forced to the mat first thing in the morning.
NFC Alarm Clock https://play.google.com/store/apps/details?id=com.nfcalarmcl... is a really great and simple Android alarm. Share if anyone has a good iOS recommendation.
Neat, but is there an advantage between this and "Place the alarm clock further from the bed"?
cries in studio apartment
But even so, I wish it would force me to key in the current time to disable, that way my sleepy brain would better understand "it's time to wake up now, because it is x time".
These exist, but they're all behind NDAs and you're not allowed to have them. They're used for e.g. EMV.
https://hackaday.com/2009/06/27/avr-rfid-tag/
I think it's a M24LR04E.
Costs like $0.50.
I think these could be useful for devices where you have a limited amount of data you want to read or transfer. Like why have bluetooth and all the crap that entails when all you want to do is configure a device once.
Advantage of a separate IC is you can use it with whatever microcontroller development stack you have working.
More generally what I'm seeking is something in the card form factor which is suitable to store cryptographic secrets (i.e., a smartcard).
Separate IC is a disadvantage here since it creates a vulnerable security boundary and makes it infeasible to integrate the chip into a thin card.
Too many times I have been stuck in 15-20 minutes queues to buy those tickets and you cant refill them with an app... Plus south shore and north shore have they own system it's a mess.
There’s the OMNY card, and I believe the original plan was to outsource sales and top-ups to third-party stores, but lately I’ve also seen some vending machines for that in some stations, so maybe they’re going back a bit on that idea.
In the old days you’d nominate a specific station, and the credit would be transferred to the card the next time you tapped in at that station.
But now days I don’t think you need to do that: presumably it maintains the balance primarily on the server side now rather than on card.
I remember using that feature in the SF bay area, and while it took a day for the top-up to actually propagate to all readers, it even worked on buses, so they must be uploading that data everywhere.
That type of connection needs to be there in any system that supports lost/stolen card value recovery, in any case, since that's how card block lists are distributed.
But yes, for speed/redundancy they are still probably using the stored value balance too.
TfL likely need that mechanism primarily to synchronize the list of blocked open-loop bank cards with unpaid balances to all readers. Faster Oyster transaction list updates and any-station remote top-ups are probably just a side effect of that.
Clipper doesn't (yet) support open-loop bank cards yet, so for them, it's probably enough to update more remote readers every time the bus goes back to the depot, for example.
- Full offline support (i.e. both the reader and payment device don't need network connectivity), making the system more resilient
- Symmetric cryptography and highly optimized transaction flow, making reads more reliable and allowing faster customer flows through transit gates
- Upfront transparency about charges, monthly passes, capping etc. – you immediately see your balance left after tapping.
- No "transaction spam". This is more on my specific transit provider (NYC MTA), but I'm really not a fan of getting an individual credit card charge for every. single. tap. It can't be cheap in terms of fees for the operator either! At least other systems, like TfL in London, aggregate taps over a day, but it's still not great.
Singapore's public transit agency recently attempted to switch from a stored value based model to an exclusively account based one, but had to backpedal quickly due to public outrage about the move.
Ideally, a system supports both payment methods: Open-loop payment cards for infrequent users, and stored-value cards (both physical and in digital wallets) for heavy users and anybody else that prefers them. But realistically, maintaining both is too much of a burden for many transit agencies.
I would argue that contactless debit/credit card or mobile wallet taps are substantially more convenient for tourists and occasional users – if you are fresh off the boat (or off the plane – for a more modern twist), not much can beat the convenience of turning up at the turnstile, tapping on and getting on with the trip on the local public transport network and tapping off at the end of the trip.
No need to look for a place that sells local rechargeable or disposable NFC cards, having to be aware of a low balance, looking for a place where the card can be topped up, actually top them up and stuff like that. For frequent travellers, it also entails having fewer non-portable mass transit payment cards to carry.
Bonus points: debit/credit card/mobile wallet payments also eliminate the problem of the discovery and consolidation of lost balances when a card gets lost, and it reduces the environment impact (manufacturing + energy consumed during the process) and the wastage (the disposal or, rather, the lack thereof) that disposable NFC cards inherently possess.
That is what Sydney (the one that is not in Canada) has done: they went straight from prepaid paper tickets to their own rechargeable Octopus/Oyster style cards (with the name also beginning with an «O» – Opal) followed by enabling debit/credit card (Visa/MC/AmEx) and mobile wallet NFC payments later within the larger metropolitan area public transport network on buses, ferries, trains and trams.
Convenience, as always and of course, comes at the expense of privacy, though.
I suppose it is a matter of personal or circumstantial preferences so I won't go into that, but through reading this discussion, I have learned that, e.g. the Boston MTBA's CharlieCard, have an expiry date and has to be replaced in person. From the regular commuter's point of view it is a nuisance of epic proportions – to turn up at a bus stop or a station only to find out they are unable to pay because their dedicated card has expired. The commuter is only interested in the act of paying the fare and not in complexities of the local mass transit system's payment network shenanigans.
I also can't help noticing that the wallet (the purse style) making business has taken a hit in recent years due to the rapidly decreasing circulation of cash and the rise of mobile wallets. Many people now leave their homes with their smartphones and keys only. Eventually and inevitably, all cities will embrace either the integration with or adoption of mobile wallets, but that will take a while depending on how well each government funds its local public transport agency.
Apple Wallet supports transit cards for dozens of transit systems, and most of them have some associated app to allow managing monthly passes or topping up the balance. Arguably, that's the best of both worlds.
Apple Wallet supports neither the Montreal (the subject of this discussion) nor Boston CharlieCard transit cards nor many more. Apple Wallet has promptly shown some transit cards from mainland China, 1x from France, 1x from Hong Kong, 3x from Japan and only 3x (!) from the US (Clipper, SmarTrip and TAP). That is all it supports. Android may support more.
The said CharlieCard[0] supports a bespoke mTicket app that is neither integrated with the mobile wallet nor fully supports all modes of transportation in Boston:
Which brings me to the main caveat. Compared to debit/credit card payments originated in a mobile wallet, supporting each transit card in existence is an extra effort that places the onus at least on the vendor of the mobile operating system and usually on the local government as well. Generally, governments do not have a good track record at delivering modern digital solutions to their citizens and are inefficient at engaging the smartphone vendors. So at the very least, the governments are slow to instigate a technological change.And, since the onus is also on the government to upgrade NFC readers across the entire network anyway – to support modern ways of paying, the question is which one is more future proof: 1) natively supporting a local transit card at the smartphone level + upgrade the NFC readers to support a variety of NFC protocols, or 2) upgrade the NFC readers to support the debit/credit card and mobile wallet payments only? I am inclined to think that (2) is more efficient and more cost-effective for taxpayers.
[0] https://www.mbta.com/fares/charliecard
But practically, a lot of them are run by a small set of contractors anyway, not any government entity directly. These only need to integrate with wallet providers once; beyond that it's just a matter of contract terms and uploading a few new assets to Apple's and Google's servers. (I believe Apple can even launch new transit cards without an iOS update these days.)
You can now refill the rechargeable OPUS cards using an app.
That still seems expensive for a $3.75 metro fare.
2.4% of the cost of your ride is the chip in the ticket itself? Maybe it's worth it because it lets them eliminate mechanical ticket-reading and unify paper tickets with other NFC payment methods.
The vast majority of users will use rechargeable Opus cards [1] that can contain a variety of different fare types (single tickets, monthly tickets, etc).
From an operator's point of view it definitely makes sense to only have to maintain one type of reader, even if that means losing a few cents profit on the low single digit percent of rides that use the disposable tickets.
[1] https://www.stm.info/en/info/fares/opus-cards-and-other-fare...
However oyster really is in its way out for most uses. contactless and especially a phone is far more convenient for non season use, and far less wasteful.
https://tfl.gov.uk/fares/free-and-discounted-travel/national...
I'm looking forward to not having to choose one trade-off over the other.
It’s still fast enough that it will read my Apple Watch before the gate starts to close from the passenger in front of me.
One saved trip to an Oyster top-up machine will make up for a lifetime of contactless NFC latency!
The Japanese transit cards that are supported by Apple Pay have that option, and it's arguably the best of both worlds.
It is, there’s even an auto top-up option that adds credit automatically if your balance drops below a certain level.
But there’s no “digital” Oyster card, only physical ones. If you want to use a device to pay you have to use contactless.
And either way, it’s still kind of a pain to have to maintain a balance - especially if you’re a tourist or visitor and don’t know exactly how much credit you’re going to need.
I agree that being able to load a transit card into Apple Pay etc is also a good solution. The convenience of not having a physical card that can be easily lost or forgotten is probably the biggest benefit for me.
Octopus (used in Hong Kong) is the one that supports virtual cards in Apple Wallet.
In Japan credit card transactions routinely take a couple seconds. Imagine each person taking 5 seconds to go through the gate! I think what trials for credit card payments in transportation services there are doing is simply not processing the transaction inline, and just doing it after the fact (assuming it will go through).
If you try to use a card that is valid but has no available balance/credit, it might work for the first ride but then be blocked when you try to use it for the return trip.
Fares are batched throughout the day and you are charged once, overnight, for all rides that day (after applying any multi-ride discounts, etc).
This is different from some other cities where I’ve used contactless payments and they’d charge you immediately for each ride, giving you lots of annoying little charges on your bank statement!
Don't ask me how though
Wrong. With the traffic volumes normally seen in Tokyo, those few hundred extra milliseconds will cause huge delays at the fare gates. There's a reason the systems here use the Felica card which processes in 100ms: it's really needed for this kind of pedestrian volume.
https://support.apple.com/en-us/118625
You don't have to unlock your phone -- just tap. If you have an Apple watch, just put your wrist to the reader.
I use this all the time in NYC and it's so fast.
Here's a good summary of NFC protocols used for transit gates: https://atadistance.net/2020/06/13/transit-gate-evolution-wh...
The Felica standard is fastest at 100ms per tap, and is used in Japan (e.g. Suica card) and Hong Kong (Octopus card).
It's conceptually very similar to MIFARE – a fixed function IC implementing a fully offline stored value purse – but uses a stack that differs from ISO 14443 A on pretty much all layers. (It was planned to possibly become ISO 14443 C, but that never happened.)
Yes: Felica was developed by Sony in Japan, but was actually first adopted in Hong Kong, then later in Japan. It's far better than other standards, because it's so fast.
The only ones that I came across that are not Mifare, and not even readable by Android (but readable by the Flipper Zero), are the paper tickets used in Brussels. Then, of course, there are non-NFC tickets. For example those that use magnetic stripes, like the cute tiny ones in Paris or NYC's MetroCard.
There are two distinct types of Oyster card, but I don't know which is which, other than from a user perspective. All I know is that I had an old style one (the one without the white D in a blue square on the back) and you could still use it, you just couldn't "connect it" to the app so you couldn't look up your travel history.
There was a complicated process for returning it and getting a replacement, but as they'd already phased in paying by bank card by then, and the only advantage of an oyster card was for season tickets, I just returned it and got my deposit back.
But if you're into collecting different card types, you might want to try to get hold of one of these old ones as well. They're probably somewhat rare now, as they were encouraging people to upgrade to the new ones at least 5 years ago.
We’re now down in the single digits for fabrication in nanometers, although I know that sort of just a name. This chip is so tiny already, if you were to fab it on a process like 7 nm I’m guessing it would be unworkably small. Too hard to cut, too hard to manipulate individual chips once you did manage to cut them.
So here’s my question: how small can we make a chip in area while still being able to cut them out and easily use them?
It’s obviously not a concern for the hundreds of square millimeters of a large processor, but I’ve never heard about the opposite end of the spectrum before.
Looking at a random die pick-and-place machine [1], it handles dies down to 0.2mm in either dimension. So you could handle smaller dies than mine with an off-the-shelf machine, but not a lot smaller.
[1] The video of the die machine in action is pretty cool: https://www.syagrussystems.com/dts-2-die-sorter
The increased losses due to cutting make sense too. I was expecting the cuts to be wider than 20 µm, so that’s not actually as bad as I was imagining.