Hacker News Reader

Comment by kens | Hacker News Reader

Author here for all your NFC chip questions :-)

That was a god read, thank you.

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.

And if a machine jams not only do you need staff to spend hours to repair it, but you need to pay staff, or contractors, to do it.

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'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?

Maybe some kind of custom NFC command that writes the UID into the EEPROM and sets a flag that it's now read only?

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).

[0] https://www.nxp.com/docs/en/data-sheet/MF0ICU1.pdf#G4008599

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."

How do they make the chips so incredibly thin?

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?

https://en.wikipedia.org/wiki/Wafer_backgrinding

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.

You have to hang out to get the id of a simple 125khz tag too - this is what cloning means

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.

Thanks for the write-up.

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)?

That seems like a question for @lxgr :-)

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.

How and why did you learn about this topic? :)

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).

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?

Not an NFC chip question, but what kind of microscope do you need to get silicon photos of a chip so tiny?

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.

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.

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?

I don't know personally about the antenna manufacturing, but one web page talks about printable conductive silver ink for producing RFID antennas. https://www.sunchemical.com/product/printed-antenna/

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 really enjoyed this read, thanks.

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!

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.

[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...

Could someone just use an nfc enabled phone to get it to act as a ticket?

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.

Layer 3 and down yes, 4 and up depends

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.

More CharlieCard NFC info:

https://medium.com/@bobbyrsec/operation-charlie-hacking-the-...

https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20pre...

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.

Definitely, but my point is that that’s not the only way to do it.

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.

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.

How much cheaper and smaller can they get before we see them used in parcel and freight?

Several such pilots for this have been in flight the last couple years.

You already see RFID tags used in retail so I would not be surprised if that isn't already the case somewhere in the shipping industry as well.

I imagine those can use even simpler chips that are completely read-only over the air and only have a UID programmed.

Reply on news.ycombinator.com