Anil John
Making Digital Services Secure and Trustworthy

Anil John

RFI - EMV Enabled Debit Cards as Authentication Tokens?

 Tweet  Share  Comment  Print  Email

The U.S. is finally moving to EMV compliant payment cards. Can these cards be used as multi-factor authentication tokens for electronic transactions outside the payment realm? What are the security and privacy implications? Who needs to buy into and be in the transaction loop to even consider this as a possibility?

I am trying something new in order learn more about a topic that is relevant to those who secure digital services. In my Request for Information (RFI) blog posts I will discuss a topic I am researching. Please expect my current knowledge to be incomplete and potentially wrong.

If you are knowledgeable about this topic and are willing to share, please leave answers and pointers in the comments below. Alternatively, if you are in the DC or Maryland area of the U.S., I would love to get together over lunch or a coffee to chat in person. We can also set up a time to chat via Skype or Google Hangout if that works better for you. You can contact me here.

EMV in the U.S.

The U.S. is finally moving to catch up with the rest of the world in implementing Integrated Circuit (IC) technology for secure payment transactions that are compliant to the EMV Specifications. This includes, but is not limited to, card and terminal evaluation, security evaluation, and management of interoperability issues which are overseen by American Express, Discover, JCB, MasterCard, UnionPay, and Visa.

I am going to side-step the “Chip and Pin” vs “Chip and Signature” debate and focus on leveraging existing user behavior to ensure that disruptive innovation is non-disruptive to adopt within the context of digital service delivery.

Debit/ATM Cards vs Credit Cards

There are three reasons I am focusing on EMV Debit/ATM Cards instead of Credit Cards:

  1. The user experience of a customer does not change when using an EMV enabled debit card. Customers know that for debit cards they have to memorize a PIN (same as now). This, I personally believe, will be huge.
  2. Debit cards are for gaining access to your checking and savings accounts. The account opening process for checking and savings are regulated and have to comply with the Know-Your-Customer (KYC) requirements and the FFIEC Authentication guidance. A clear foundation for why this token could be trusted as part of an authentication process.
  3. Financial institutions already have an existing infrastructure in place for the lifecycle management of PINs associated with Debit Cards which can be leveraged for the EMV Debit Card roll out. The recent announcement by Bank of America that they will “… include chip technology on all new and reissued consumer and small business debit cards” is a clear example.


  • Is there a difference in KYC requirements when it comes to opening checking/savings accounts vs credit cards?

Data Security, Integrity and Contactless Features

I am sure there data security and integrity checking features built into the card itself to prevent cloning and other attacks. I accept that they exist but am not focused on that right now.

In addition, for the sake of clarity I would like to focus on contact features of the card without being distracted by the complexity of contactless/NFC.


  • Are there decisions made by a card issuer for a contact card that in the future could limit or prevent its transition to having a contactless interface?

Validating the EMV Chip

There appears to be a mechanism to validate the EMV chip and the messages that are flowing from it and to it. I keep hearing the phrase ‘cryptogram’ in association with this. In particular I’ve run across the terms ARQC (Authorization Request Cryptogram) and ARPC (Authorization Response Cryptogram).


  • How is the term ‘cryptogram’ used in this context? It appears to be analogous to a digital signature for authenticating the sender and for ensuring the integrity of the message. Is that right?
  • How are these ‘cryptograms’ generated? Who generates them? Who validates them?
  • What is the role of the EMV chip in this flow?
  • What is the role of the merchant terminal in the flow?
  • What is the role of the issuing bank in the flow?
  • What is the role of Amex, Visa, Mastercard in the flow?

Validating the Primary Account Number (PAN)

Once the EMV Chip (i.e. the Card) has been validated, the Debit Card Account Number (i.e. the PAN) needs to be validated to ensure that it was indeed issued by a particular FI and that it is still valid and active at that FI.


  • How is this done?
  • Who is in the flow for this?
  • Who can see the cleartext PAN? The merchant terminal? The issuing bank? Amex/MC/Visa?
  • Does the compromise of the PAN only (i.e. the PIN is secure) allow for usage of the debit card for any financial transaction?
  • Does the knowledge of the PAN compromise in any way the identity of the card holder?

Verifying the Customer

EMV specifications support multiple Customer Verification Methods (CVMs):

  • Offline plaintext PIN
  • Offline enciphered PIN
  • Offline plaintext PIN and Signature
  • Offline enciphered PIN and Signature
  • Online enciphered PIN
  • Signature
  • No CVM Required
  • Fail CVM Processing

The one that is of particular interest in its use for authentication usage is ‘Online enciphered PIN’, similar to how a typical ATM is configured.

From what I’ve been able to find out, it appears that a card issuer configures a card with a list of CVMs it supports. In addition, a terminal is configured with a list of CVMs it supports as well.


  • Is the card listing of the CVMs prioritized?
  • Is the terminal listing of CVMs prioritized?
  • Whose priority takes precedence?
  • Can the PIN challenge be supported on every request?
  • Can a terminal support ONLY ‘Online enciphered PIN’ as a CVM?
  • What does ‘enciphered’ mean in the context of the PIN? Who does it? How is it validated?
  • Who has access and visibility to the PIN as part of the validation flow? What do they see?

Who Needs to be In the Loop to Make this Work?

At the end of the road, I am trying to understand three things:

  1. Who needs to be aware that such a transaction is happening, but is not impacted by it because it conforms to the existing transaction flow?
  2. Who needs to make changes to their infrastructure to support such a flow?
  3. Can the existing payment processing liability and distribution of the ‘cut-of-the-action’ structure be leveraged for this purpose?

Could an organization look to a future in which instead of a merchant account with an FI, it establishes a ‘relying party account’ with them for this purpose or is a merchant account all that is needed? Are there regulatory barriers that would have to be addressed?

BTW, I can also envision a future where a broker establishes relationships with multiple FIs to validate EMV Debit Cards and offers that as service to RPs.

And would that future, from a consumer perspective, simply be a matter of downloading software to their device and using a card reader to assert the PAN to a relying party as part of an authentication flow? The expectation being that the RP would then have to do the identity proofing to link the validated identity to the PAN.

If the banks are not willing to enter into this game, what role could someone like Paypal or Square or someone similar have in this mix?

As I mentioned before, I have more questions than answers on this topic so am very much looking forward to the discussion!


Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

This blog post first appeared on Anil John | Blog ( The opinions expressed here are my own and do not represent my employer’s view in any way.

By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post. Please leave a comment below!

I am a Public Interest Technologist. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone