I have received conflicting information in regards to the security of PAN data on the wire. Can this be sniffed with properly configured EMV at an atm?

To quote from the link below: http://www.firstdata.com/downloads/thought-leadership/EMV-Encrypt-Tokenization-WP.PDF

The PCI Security Standards Council notes: “in EMV environments, the PAN [primary account number] is not kept confidential at any point in the transaction.”

However from my understanding a fundamental part of a EMV transaction is that the processor forms a cryptogram of the PAN that can only be decrypted by the issuer/processor (CDA/DDA). Making any captured traffic useless. What would be the point in sending PAN when there is already a unique way of identifying the card? See quote below:

"All EMV cards have a mandated minimum requirement for using one card unique 3DES key and have a choice between three increasingly secure usages of RSA signatures and keys, termed SDA (Static Data Authentication), DDA (Dynamic Data Authentication), and CDA (Combined Data Authentication)." https://www.cryptomathic.com/hubfs/docs/cryptomathic_white_paper-emv_key_management.pdf

These two legitimate sources seem to contradict themselves in regards to PAN data being vulnerable to MITM attacks.

2 Answers 2


Many people are surprised to learn that EMV doesn't encrypt the PAN. But really, once EMV is fully rolled out encrypting the PAN will become unnecessary, and would be leftover as a technical debt of the current insecure protocols. EMV doesn't need to start with that baggage.

The reason EMV doesn't require encryption of the PAN is that the PAN only represents Identity; it does not represent Authentication of the chip (that's the job of the ARQC message), and it does not represent the Authorization of the cardholder to use the card (that's the job of the PIN). As long as the chip is authenticated, and the user provides the authorization, the transaction is secured. The identity doesn't have to be kept secret.

In today's non-EMV world, identity, authentication, and authorization are all three combined on the unchanging mag stripe. Copying the stripe data enables you to clone a card, so protecting the whole stripe is required. We use the words "identity theft" so people think they're stealing our identity, but really, they're stealing all three attributes from the card at the same time.

With EMV, the PAN is still required to provide the identity of the card. The rest of the EMV data does not include enough information to otherwise identify the card, nor should it. The identity can even be made public, as long as it can't be used by itself.

In EMV, the ARQC cryptogram serves as the signature from the chip, authenticating the messages originated from the chip associated with the PAN. Cryptography and secure storage on the chips ensure that an ARQC can't be forged. Because the ARQC is transactional, every request is different; replay attacks don't work as long as the bank ensures duplicate ARQCs are rejected.

The PIN serves as the user's authorization to charge. The PIN tells the chip "hey, your user just proved right now that he wants this transaction to go through." It's up to your bank if they want your card to require a PIN; they might be happy just letting you sign for the transaction.

[ Note that most U.S. banks opted for Chip and Signature instead of Chip and PIN. The only advantage of Chip and PIN is that it protects your card from unauthorized use if it's lost or stolen; but really, the FDIC already limits your personal liability to $50, and almost all banks waive that to $0 in the case of a lost or stolen card. And since the banks make money every time you charge anything, they'd rather accept the risk of fraud (that they're already obliged to take by law) than to inconvenience their customers by making them type a PIN. They believe that inconvenienced customers will find an easier way to pay, cutting into their profits.]

But we're a long ways away from full EMV rollout. The October 2015 liability shift was created as incentive for U.S. retailers to change their transaction processing to use EMV, but very few U.S. retailers actually take chip cards as of April 2016. Rolling out new terminals, new software, and new cards across 6 million retailers, 11,000 banks, and billions of cards takes a lot of time and money. And nobody's yet created a universally accepted solution to secure Card Not Present (CNP) transactions, such as hotel bookings, web purchases, etc. So until EMV is fully deployed and the CNP problem solved, it's still up to merchants and POS terminals to protect and encrypt the PANs and the sensitive authorization data. For now, that includes the PAN.

  • The core problem of EMV still sending out an unencrypted PAN is this : that PAN is important as authentication in card not-present transaction fraud. (Yes, in many cases a CVV code from the card may be required, but that's not remotely equivalent in security value to what EMV cryptograms can provide for card-present authentication.) The designers of EMV made a huge mistake when they just assumed that strong authentication for card not-present transactions would just materialize in the near future, and that therefore keeping the PAN secret during card-present uses would cease to matter. Commented Apr 4, 2016 at 21:31
  • EMV is about ten years from rollout, so PAN encryption is going to be with us for a long time yet. The primary problem, though, is leaving the creation of 'secure' alternatives to CNP to the marketplace. They should have specced a low power display on the cards with a rotating CVV, or mandated card readers for web browsers, or something. Instead, we've got Apple and PayPal each trying to take a usurious cut of the web's profits. Commented Apr 5, 2016 at 3:49

The PAN is still as vulnerable to compromise in an EMV transaction as it was without EMV, if no additional security measures are taken. The cleartext, static PAN is still included in the transaction message, in addition to the cryptogram. The statements you quoted above are both true. SDA/DDA/CDA usage is around the crypto operations performed with EMV. Separate from that, the PAN is still included in another field than the one the cryptogram is sent in.

As far as "on the wire goes", PCI DSS requirements do specify that PANs be encrypted when transmitted over open, public networks such as the Internet. Encryption on private networks is not mandated.

Many solutions are implementing Point-to-Point Encryption (P2PE) on top of EMV to help protect the PAN.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .