Bye-bye Cards App as a cEMV Card

Bye-Bye Cards App

The following is an example of a cEMV session between a validator’s NFC card reader and a CRD that is a smartphone with installed app Bye-Bye Cards.

Bye-Bye Cards app is an app that demonstrates how CRD Token is used in UniTiAg Open-Loop ticketing model.

Bye-Bye Cards is not a payment app. Its EMV AID does not represent a payment EMV application, and there is no payment data exchange in this session. The cEMV protocol is implemented solely for the purpose of compatibility with the existing cEMV card readers. This example demonstrates that the proposed card reader logic is already implemented in regular cEMV card readers.

This approach makes it easier for ticketing system vendors to integrate with UniTiAg, and fully exempts transit agencies from the complexity of PCI DSS and payment scheme regulatory obligations.

CRD Token Apps in UniTiAg

An app similar to Bye-Bye Card can be implemented by any TSMP participating in UniTiAg. Alternatively the TSMP may opt to use Bye-Bye Cards. The TSMP is responsible for generating its unique CRD Token, according to the TSMP API, and managing its CA Public certificate.

UniTiAg maps the PKI Public Key certificate X.500 “O” (organization name) to participating TSMPs

Example of cEMV Session

During this session, the app emulates a cEMV card. The ‘card” presents the CRD Token to the card reader and proves its authenticity using a simplified cEMV approach.

The entire NFC session time takes around 200 msec on the modern smartphones. Let’s walk through it step-by-step.

The APDU request/response trace is obtained with app NFC EMV Explorer which can be installed from Google Play Store here.

Step 1: Select PPSE 2PAY.SYS.DDF01

This step is implemented for the compatibility purposes. It is not mandatory because the card reader knows exactly which AID to select in the next step. If this step is executed the smartphone’s operating system may direct the NFC session to an app with a higher priority, e.g. a Wallet.

APDU Request/Response Trace:

Select PPSE APDU Request: 00a404000e325041592e5359532e444446303100

Transceive Time=31 msec. SW1/SW2=9000.
Response content:
6f   FCI Template, length=41
  84   Dedicated File Name, length=14
    "2PAY.SYS.DDF01"
  a5   FCI Proprietary Template, length=23
    bf0c FCI Issuer Discretionary Data, length=20
      61 Directory Entry, length=18
        4f ADF Name, length=7
          f5633545180001
        50 Application Label, length=7
         "UNITIAG"
---- End of Response Content.

Tag 4F comprises the AID of the CRD Token app

Step 2: Select ADF

The card reader selects Application Data File for the AID F5633545180001.

APDU Request/Response Trace:

==== Select ADF APDU REQUEST: 00a4040007f563354518000100.

Transceive Time=15 msec. SW1/SW2=9000.
Response content:
6f   FCI Template, length=49
  84   Dedicated File Name, length=7
    f5633545180001
  a5   FCI Proprietary Template, length=38
    50   Application Label, length=7
      "UNITIAG"
    9f38 PDOL, length=8
      9f1c089f37049a03
    df01, length=15
      73084de18d15f9ac4734662814d4bb
---- End of Response Content.

In tag 9F38, the “card” requests from the card reader  9F1C (Terminal ID, 8 bytes),  9F37 (Unpredictable Number, 4 bytes), and  9A (Transaction Date, 3 bytes).  In tag DF01, the “card” presents the 15 byte-long CRD Token.

At this point, the validator can initiate a parallel process to look up the CRD Token in the validator’s OTRB list (don’t forget to re-encode the binary value on DF01 to Base64-encoded string), and continue with CRD Token offline data validation (next steps).

Step 3. Get Processing Option

On this step, the card reader presents the data objects requested in the PDOL which the “card” signs with its private key and returns the Signed Dynamic Application Data.

APDU Request/Response Trace:

==== GPO APDU REQUEST: 80a8000011830f30303132303031325cb0b6f725122000

Transceive Time=34 msec. SW1/SW2=9000.
Response content:
77   Response Message Template Format 2, length=73
  94   Application File Locator, length=4
    08010202
  9f4b Signed Dynamic Application Data, length=64
     7f54 ... db
---- End of Response Content.

Tag 94 points to file 1, records 1 and 2. The card reader obtains these records on the next step and uses them for Offline Data Authentication.

Step 4. Read Records

The terminal reads two records specified in the AFL tag . The records comprise the public key X.509 certificate issued by the TSMP’s Certification Authority. This is the last step of the NFC session.

APDU Request/Response Trace:

==== Read Record 1 in file 1 APDU REQUEST: 00b2010c00.

Transceive Time=44 msec. SW1/SW2=9000.
Response content:
70   Read Record Response Message Template, length=244
  9f46 ICC Public Key Certificate, length=240
       3082  ...  d718
---- End of Response Content.

==== Read Record 2 in file 1 APDU REQUEST: 00b2010c00.
Transceive Time=36 msec. SW1/SW2=9000.
Response content:
70   Read Record Response Message Template, length=190
  9f48 ICC Public Key Remainder, length=186
    0a56 ... a8c4
---- End of Response Content.

Step 5. Offline Data Authentication

Upon finishing the NFC session, using the ICC Public Key, the PDOL data, the Signed Dynamic Application Data, and the well-known Certificate Authority public X.509 certificate, the card reader completes offline data authentication.

The card reader also compares the CRD Token obtained in Select ADF stage, tag DF01 with ICC Public Key Certificate component Certificate Name “CN’. The latter also presents the CRD Token encoded as a 30 char-long string of hexadecimal digits. In this case it must be “CN=73084DE18D15F9AC4734662814D4BB”

More about Bye-Bye Cards and its integration with Telegram Web App – in our blog.