How to make a pass scan as static UID

Richard Grundy

Updated May 13, 2024 07:07

Overview

Developers frequently need to integrate new technologies into existing systems to offer more compatibility and convenience. Legacy NFC readers were originally built to read static ids off of NFC cards and keyfobs. Once identified by the reader, a connected PC could activate a gate to open or a reward to be redeemed. Now that mobile phones and smart watches have NFC chips built-in, it makes sense to include them in these legacy systems. I much rather carry my phone or watch than a bunch of cards and keyfobs, wouldn't you??

Evolution of NFC

NFC has been around for decades, originally coming out of the RFID industry. Developed by Sony and Philips in the early 2000s, researchers changed the far field nature of RFID systems to work in the near field only - like a couple inches. This saved a ton of power allowing portable electronics to exchange data that could trigger more compelling experiences. Both passive (no battery) and active targets were supported so this enabled many new use cases from payments to media sharing.

The key was that targets needed to be identified uniquely to allow for secure data exchange. Early transit cards supported static unique identifiers (UIDs) of 4 bytes in length. These worked well until adoption grew so much that reproduced cards were often encountered. NFC chip makers upgraded to universally unique identifiers (UUIDs) of 7 bytes to address this problem. As populatirty for these UUIDs cards grew, so did the value of the transactions they initiated and the need for stronger security to prevent fraud. This prompted the payments industry to develop NFC cards with encryption codes that changed on every tap. Deemed the most secure encryption schemes, these were adopted more broadly whenever sensitive data needed to sent over NFC.

Static vs Dynamic UIDs

The early work from Philips and Sony led to the formation of the NFC Forum to define the NFC standard. The earliest NFC tag specifications were Types 1 though 3 based on static UIDs; the most popular being Type 2 led by Philips under the product "MiFare Ultralight" and Type 3 led by Sony under the product "FeLiCa" mainly in Japan. Nine times out of ten, if you encountered an NFC tag in the world it would be a MiFare Classic (proprietary) or a MiFare Ultralight. These were super cheap to make and really easy to build a solution with. Just store all the UIDs in a look-up table and pair them with a desired experience.

Dynamic UIDs made things inherently more complicated... even without encryption. Outlined by the NFC Forum Type 4 tag specification, there have been several vendors making these chips and each with their own way of accessing data. Simply sending and receiving commands (known as APDUs) to Type 4 NFC targets takes writting low level software and understanding interfaces like CCID, PCSC, and ISO-7816. It's no wonder developers resist adopting Type 4 tags in their projects unless hardend security is an explicit requirement.

Apple and Google Wallets

All virtualized cards in the Apple and Google Wallets have dynamic UUIDs. This is because payments requires hardend security. So when Apple and Google set out to build their wallet applications, they followed the NFC Forum Type 4 specification. If you want to read data from these apps you must send APDU commands dictated by the type of card or pass you want to access. There are three types currently supported: Contactless EMV cards, Access passes, and VAS passes.

1. Contactless EMV cards are the Tap to Pay debit/credit cards that are now popular all over the world. Virtualizing these on mobile devices adds a layer of security since the wallets support biometrics to authenticate the user on every transaction. The EMV contactless protocol is very mature and most point-of-sale devices support it natively. Surprisingly, this also includes phones; albeit ones with NFC hardware running iOS 17.0+ or Android 10+.

2. Access passes are meant for highly secure access control use cases and behave slightly differently between Apple and Google Wallets. Apple requires NFC readers to support a proprietary Enhanced Contactless Polling mode in order to autoselect and interact with Access passes. These passes are even readable if their host iPhones are powered down (known as Express mode). Google follows the NFC Forum Host Card Emulation (HCE) mode and only standard APDUs are needed to work with their Access passes.

3. VAS passes are used for loyalty and couponing as well as some light access control cases like event ticketing and boarding passes. They require NFC readers to support the Apple VAS and Google SmartTap protocols to autoselect and decrypt them. Like with Contactless EMV, there has been efforts to read VAS passes from other phones with NFC hardware (details here) but are still limited (no x-functionality).

Integrating mobile devices into legacy systems is challenging because Apple and Google Wallets are built using dynamic UIDs, non-standard NFC modes, and involve complex pass issuing workflows. Also, any upgrade to a legacy system will need to support NFC cards and keyfobs with static UIDs unitl they can be phased out over time. And finally, the recurring cost of ownership needs to remain on par after the upgrade.

Making NFC easy with PassNinja

PassNinja makes it easy to create passes on Apple and Google Wallet (with NFC). You'll need to sign up for an account and select a pass template with the card type you want to emulate. Right now we only support VAS passes but adding more soon.

Next you'll need to top up you account to cover our service fees. We accept credit card and crypto as payment options. Once the pass template is created, you can fill in a phone number and set the pass NFC message field to the static content you want. This will issue a pass and send it over text message.

Once you have the pass installed on a mobile phone, you'll need an NFC reader that supports the VAS protocol and is set to detect your pass template. We sell an NFC Devkit that includes a DotOrigin VTAP100 pre-configured to decode your passes and ships globally with fast turnaround times (<2 days US domestic, <6 days international). We found it to be the best generic option, however there are many reader options on the market that can work.

And there you have it. An Apple or Google Wallet pass that scans as a static UID over NFC for you to easily integrate into any legacy systems. What's great is that the VTAP100 supports NFC Forum Type 1 through 3 tags as well so original cards and keyfobs will still work!

Conclusion

In this guide we went through some NFC history as it relates to static and dynamic UIDs. We covered how dynamic UIDs are more secure and the only option supported by Apple and Google Wallets. We then showed you how PassNinja lets you bridge the gap between the wallets and legacy systems so you can integrate mobile devices and smart watches easily. We are excited to deliver a better experience to your users in every way.

If you have any feedback on this article, let us know! Email content@passninja.com