Reverse Engineering Apple’s Proprietary NFC Wallet Protocol

Near-Field Communication (NFC), a technology behind tap-to-pay credit cards, has evolved significantly since the iPhone 7 in 2016. This tech now powers a range of applications, from mobile payments to access control and event ticketing, making daily interactions more convenient. However, Apple’s strict control over NFC in iPhones, requiring costly fees and agreements for access, has sparked efforts to decode their proprietary system. This summary highlights both the expansive potential of NFC and the challenges posed by Apple’s restrictive policies.

Near-Field Communication (NFC), a subset of Radio Frequency Identification (RFID), is a decades old technology that employs short-range electromagnetic fields to provide power to, and establish a communication channel with a small, embedded device. The perfect example is the tap-to-pay option on a credit card. This creates an extremely convenient and intuitive user experience in cases where short and fast interactions for authentication or identification are necessary.

Since the launch of the iPhone 7 in 2016, payments — the most widespread use of NFC technology — have steadily transitioned from passive cards towards tighter integration with the complex mobile devices people carry with them. This integration generated diverse opportunities to utilize this tech in many other cases, such as access control, event ticketing, points & rewards programs, and memberships — all while promising to reduce the number of cards and keys the user must carry.

Apple maintains tight-gripped control over the NFC chip within their iPhone lineup, frequently opting to pay millions in fines weekly rather than comply with government anti-trust orders to open access to NFC. Apple’s proprietary Value Added Service (VAS) protocol is one of the only options for third-party developers seeking to integrate NFC into their services, and gaining access to its documentation requires signing non-disclosure agreements and paying significant fees. This blogpost, motivated in part by these hurdles and by Apple’s obstinate attitude, presents this proprietary protocol reverse engineering results.

The Method and its Obstacles

When a passive NFC card or mobile phone enters the electromagnetic field of a reader, NFC (more specifically ISO 14443) can be abstracted away and thought of as any other hardware communication channel. Reverse engineering the protocol then becomes about observing the traffic between the devices. The proxmark3 is an existing hardware security research device intended to

create, test, and execute attacks on RFID technologies. If the proxmark3 device is placed between an iPhone and a VAS reader, it is possible to record the bytes flying back and forth, a sort of physical, electromagnetic version of Wireshark. Despite the hurdles Apple puts in place, there was some early adoption of Apple Wallet passes in the marketplace. Large restaurant chains often use this technology as a part of their rewards programs because of the convenience for customers and tight integration with Apple Pay. However, the exercise of monitoring the behavior of the Apple Wallet pass on the iPhone could definitely appear nefarious; holding a suspicious black box with blinking lights near credit cards and contactless payment terminals in a restaurant while surrounded by employees and customers might not be reassuring.

Fortunately, I soon came across ChargePoint’s electric vehicle chargers, which use the VAS protocol and are conveniently left unattended in countless parking lots (see Image 1).

Image 1. ChargePoint Charger

An Overview of the VAS Protocol

After capturing several successful transactions between the digital NFC card on the iPhone and vehicle charger, it became clear that VAS was an amalgamation of proprietary NFC polling frames (technically a whole separate custom Apple protocol called Enhanced Contactless Polling/ECP) and ISO 7816 commands. These commands are organized into Application Protocol Data Units (APDU’s), which define a structured way to send instructions to NFC cards (see Diagram 1). The VAS transactions observed began with a standard SELECT command, which is used by a reader to tell a multi-protocol card which protocol, or “applet,” it is going to use. The applet identifier for VAS is the string “OSE.VAS.01”. The “OSE” component of this string has been referenced to be an abbreviation for “Other System Environment,” but little information is available online about what this truly means. Interestingly, Google’s competing digital wallet, Google Pay, with its own proprietary protocol SmartTap, will also respond successfully to this applet identifier, presumably to enable cross-platform pass reading within a single NFC reader. Other than this identifier, the two protocols share no technical similarities.

Diagram 1. VAS Protocol

After the SELECT command and response, the reader transmits a proprietary command, GET VAS DATA. At this point, the process of reverse engineering becomes entirely about trial and error —changing the various values within the command independently, sending them to an iPhone, and observing the change in outcome. This can be difficult within Apple’s ecosystem, as access to the filesystem, system logging, and other traditional sources of debugging and analysis information are unavailable on standard iOS devices. A jailbroken iPhone with full access to these tools was crucial in revealing additional information about the behavior of the protocol.

The part of the protocol that was of most interest was the encryption scheme used to protect the data as it is being transmitted to the reader. For digital passes such as tickets, gift cards, and memberships, all of which could hold significant value, the option to secure the pass against skimming, cloning, and other attacks provides an absolute advantage over QR and bar-codes—if the cryptography is done correctly. Before the launch of VAS passes, Ticketmaster created SafeTix, a system of short-lived, automatically updating QR codes within their app to prevent multiple concert-goers from using one ticket to gain entrance. Despite fervent claims of cutting-edge security, this system was quickly revealed to be a repackaged version of two-factor authentication code technology and vulnerable to the very attacks these « innovations » were attempting to address. This failure to effectively enhance the security of their bar-code system prompted Ticketmaster and others to pivot towards NFC tickets using VAS.

Proposing a Niche but Significant Attack

The VAS message encryption process begins with an elliptic curve Diffie Hellman between the reader’s key and the iPhone’s ephemeral key, and then an ANSI X9.63 key derivation, and finally an AES GCM block cipher. There are no obvious flaws in the crypto-system of this protocol, and it successfully prevents anyone who doesn’t have the reader’s private key from obtaining the pass data via the VAS protocol. Rest easy, your NFC-compatible gift cards, gym memberships, door access keys, and rewards cards are safe against malicious adversaries.

However, issues arise in scenarios where the owner of the pass/iPhone is also the attacker, for example a concertgoer attempting to clone their ticket for their friend. Because digital wallet passes are effectively just signed JSON dictionaries hosted on a web server or attached to an email, the VAS message is available in plain text to the user. This information is all that is required to successfully complete the client-side of a VAS transaction and convince a reader that you have the pass.

Admittedly, this is a rather advanced attack, but it can be done, and as concert and other event tickets continue to increase in price, the incentive to do so becomes more obvious. This issue is a direct result of Apple’s restrictive policies surrounding NFC on their platform, which prevent third-party developers such as Ticketmaster from creating their own NFC protocols with security measures tailored to their unique threat model. Although the code to emulate a VAS pass and complete an attack such as this will not be released here, the reverse engineered protocol specification providing more details about the commands and encryption scheme, as well as a proof-of-concept program for reading passes are available on this GitHub.

We would like to thank Dr. Andréanne Bergeron for the supervision of this research project and for further writing and reviewing of this blogpost.

Author: Grayson Martin