2

In the EMV documentation (EMV Book 3 Section 6.5.10), the PIN Change/Unblock command provides the option to change or unblock a card's PIN, and also handles resetting the PIN Try Counter (EMV tag 0x9F17) along the way. This command is an issuer script, meaning it is sent by the issuing bank to an ATM or a POS which then forwards it to the card thereby resetting the counter and optionally changing the PIN. PIN Change/Unblock command details

Referring to the details in the photo above, what would happen if I were to manually send this command to the card, setting P2 as '00' and padded the Data field as jargon bits? Would this succeed in resetting the PIN Try counter? Unfortunately, the EMV docs don't really shed light on this command like they do in others. I'm interested in the exchange of data that happens between the card and the terminal AFTER the terminal forwards the PIN Change/Unblock command APDU from the issuer script to the card.

I would also really appreciate it if anyone can point me to a software tool where I can simulate this or similar EMV scenarios.

P.S: See Guessing PIN code of smartcard using brute force and offline reader and https://stackoverflow.com/questions/53645555/pos-emv-card-pin-change for added context if needed.

OrangeJusticeV
  • 111
  • 5

1 Answers1

1

PIN CHANGE/UNBLOCK is the post-issuance command that can only be sent using issuer script. Issuer encrypts issuer script by the session key derived from "Script encryption key". The MAC is also generated over the encrypted blob using session key derived from "Script MAC key".

Both script encryption key and script MAC key are present in the card.

Issuer script is sent with the Issuer Authentication Data as shown in EMV Book 4, 12.1.3 - Authorisation or Financial Transaction Response. This happens after terminal issues first Generate AC (Application Cryptogram) command and the card responds with Authorization Request Cryptogram (ARQC) for online approval.

Without script keys, the card will reject the script. Card also has replay protection to prevent reusing the captured response from earlier transactions.

I'm not aware of any step in the typical EMV contact transaction where the card actually decrypts the cryptogram sent from the bank ~or the terminal~.

The Issuer Authentication Data contains Authorization Response Cryptogram (ARPC) to verify approval/rejection.

ARPC = MAC(ARQC || CSU || Proprietary Authentication Data)

CSU = Card Status Update (contains data sent to the ICC to indicate whether the issuer approves or declines the transaction, and to initiate actions specified by the issuer. Transmitted to the card in Issuer Authentication Data)

Issuer Authentication Data = ARPC || CSU || (optional) Proprietary Authentication Data

defalt
  • 6,231
  • 2
  • 22
  • 37