I'm having a problem with an EMV MTIP contactless test and I don't understand why. The transaction is being accepted, but my test tool is displaying some failures around the cardholder verification and the CVM used (or not used).
The issues are:
TVR Byte 3, bit 8, expecting 0, Received 1 (cardholder verification was not successful)
CVM Results are equal to 3F0001, 5F0302/0 were expected
My understanding of this is both of these are saying no CVM occurred, although it should have. I don't understand why, as the amount of 3000 is above the CVM required limit. I have my terminal capabilities for contactless set to 60 B8 C8, which indicated support for:
Plaintext on ICC
Signature
Enciphered PIN Offline
No CVM Required
As I see it, 5F0302 would indicate the successful use of No CVM Required, where as 3F0001 indicates that CVM verification failed.
Can anyone shed some light on why this would happen, and if I'm doing something wrong?
A full log of the transaction is too big to include in the post, but can be found here: Pastebin Transaction Log
Edit 1:
I'm fairly certain I'm loading the correct CAPK's. They're being loaded from an XML file as per the terminal vendor's example, with the following values:
<tag id="E2">
<tag id="DFC316">A000000004</tag>
<tag id="9F22">EF</tag>
<tag id="DFC317">A191CB87473F29349B5D60A88B3EAEE0973AA6F1A082F358D849FDDFF9C091F899EDA9792CAF09EF28F5D22404B88A2293EEBBC1949C43BEA4D60CFD879A1539544E09E0F09F60F065B2BF2A13ECC705F3D468B9D33AE77AD9D3F19CA40F23DCF5EB7C04DC8F69EBA565B1EBCB4686CD274785530FF6F6E9EE43AA43FDB02CE00DAEC15C7B8FD6A9B394BABA419D3F6DC85E16569BE8E76989688EFEA2DF22FF7D35C043338DEAA982A02B866DE5328519EBBCD6F03CDD686673847F84DB651AB86C28CF1462562C577B853564A290C8556D818531268D25CC98A4CC6A0BDFFFDA2DCCA3A94C998559E307FDDF915006D9A987B07DDAEB3B</tag>
<tag id="DFC318">03</tag>
<tag id="DFC31A">21766EBB0EE122AFB65D7845B73DB46BAB65427A</tag>
</tag>
<tag id="E2">
<tag id="DFC316">A000000004</tag>
<tag id="9F22">F1</tag>
<tag id="DFC317">A0DCF4BDE19C3546B4B6F0414D174DDE294AABBB828C5A834D73AAE27C99B0B053A90278007239B6459FF0BBCD7B4B9C6C50AC02CE91368DA1BD21AAEADBC65347337D89B68F5C99A09D05BE02DD1F8C5BA20E2F13FB2A27C41D3F85CAD5CF6668E75851EC66EDBF98851FD4E42C44C1D59F5984703B27D5B9F21B8FA0D93279FBBF69E090642909C9EA27F898959541AA6757F5F624104F6E1D3A9532F2A6E51515AEAD1B43B3D7835088A2FAFA7BE7</tag>
<tag id="DFC318">03</tag>
<tag id="DFC31A">D8E68DA167AB5A85D8C3D55ECB9B0517A1A5B4BB</tag>
</tag>
<tag id="E2">
<tag id="DFC316">A000000004</tag>
<tag id="9F22">FA</tag>
<tag id="DFC317">A90FCD55AA2D5D9963E35ED0F440177699832F49C6BAB15CDAE5794BE93F934D4462D5D12762E48C38BA83D8445DEAA74195A301A102B2F114EADA0D180EE5E7A5C73E0C4E11F67A43DDAB5D55683B1474CC0627F44B8D3088A492FFAADAD4F42422D0E7013536C3C49AD3D0FAE96459B0F6B1B6056538A3D6D44640F94467B108867DEC40FAAECD740C00E2B7A8852D</tag>
<tag id="DFC318">03</tag>
<tag id="DFC31A">5BED4068D96EA16D2D77E03D6036FC7A160EA99C</tag>
</tag>
Edit 2: The Terminal Risk Managment Data in use is 0CB4000000000000, which shows support for:
Contactless
No CVM required
On Device CVM
Contact
Plaintext PIN
Signature
Enciphered Offline
On Device CVM
Edit 3: The terminal type as set in 9F35 is 22 = Attended, Offline with Online Capability
Edit 4: The TAC for Denial is all zeros. The TAC for Default and Online is FC50808800, indicating:
Offline data authentication was not performed
SDA failed
ICC data missing
Card appears on the terminal exception file
DDA failed
Combined DDA/AC generation failed
Expired application
Requested service not allowed for card product
Cardholder verification not successful
Transaction exceeds floor limit
Merchant forced transaction online
TVR Byte 1 bit 8 = 1 - Offline data authentication was not performed
TVR Byte 3 bit 8 = 1 - Cardholder verification was not successful
This show that your terminal have no required Certification Authority Public Keys (CAPK) loaded for Offline data authentication. Load correct test Public Keys with indexes 0xEF, 0xF1, 0xFA. These keys used for both contact and contactless M-TIP cards.
You did not mention your MasterCard contactless tag 0x9F1D value - The Terminal Risk Management Data.
You did not mention your Terminal MasterCard/Maestro Online, Denial, and Default TACs.
You did not mention your Terminal Type. Attended/Unattended. Maestro should have specific implementation for unattended environment regarding NoCVM.
Terminal Capabilities Tag 0x9F33 you noticed usually replaced by your terminal brand Contactless Kernel initialization settings/tags.
I see SDA enabled in your case. According PayPass M/Chip Requirements - "Newly deployed PayPass terminals do not support SDA, and are not configured to support SDA." SDA is a weak authentication.
In the terminal Contactless Kernel you should have configured different CVM capabilities for transaction amounts below CVM Required Limit (NoCVM) and above CVM Required Limits. Because of Market requirements Online PIN might not be supported, Signature should not be supported for Unattended terminals, so, only NoCVM can be used in this case for amounts above CVM required limit. Plus specific implementation for Maestro processing.
I would suggest to look into MasterCard PayPass—M/Chip Requirements and open another interesting items about the MasterCard/Maestro contactless cards processing.
Related
I am developing an android payment application which is emv compatible. In this application con-tactless card acceptance has been integrated, how ever for the certification purposes it is required to determine the CVM applied on the transaction. for a con-tactless transaction how do we determine the CVM method applied for the transaction ? for example if the transaction amount is above the CVM limit and the user entered online pin, at the end I want to determine that ,the user has entered online PIN
There is no update from terminal to mobile app on the used CVM during tap. If using a a mobile wallet( with Wallet providers Visa and MasterCard ) you will get a notification from MDES/VTS after transaction completion, in which you can see(give a try ) whether the CVM used is present along with the transaction Approved/Declined status. If that too is not available, the only way left behind is to get it from the issuer system.
If you have "lame" EMV kernel which don't provide CVM output for CTLS then your only option is to parse it from transaction output. Unfortunately every card issuer using their specific way of "handling" CVM output.
Step 1
Determine card issuer and card type. Use AID (tag 4F) to do it.
Step 2
Visa and UnionPay EMV - you need to parse tag 9F6C - Card Transaction Qualifiers where
Byte 1 bit 8 set to 1 means Online PIN. Byte 1 bit 7 set to 1 means Signature.
JCB EMV - (JCB have 2 other modes but it's not in use in my region. Possibly it's already deprecated for whole world.) you need to parse tag 9F50 - Cardholder verification status where 00 means No CVM. 10 means Signature. 20 means Online PIN.
MasterCard EMV - (MasterCard have also MSR mode but it's not in use in my region) you need to parse tag 9F34 - CVM Results. This is same tag as for contact transactions so just check and follow contact EMV book rules.
MasterCard Mobile - I'm not 100% sure but it has to be same as for MasterCard EMV.
Amex EMV - parse tag 95 - Terminal Verification Result. When Byte 3 bit 3 is set to 1 then CVM is Online PIN else No CVM.
Amex Mobile - parse tag 9F71 - Mobile CVM Results. Check corresponding EMV Contactless book for specs.
For other issuers you have to check corresponding EMV Contactless books.
I use Thales Payshield 9000 HSM. So far, all commands has worked and everything has been achieved what i wanted.
Now the problem is when trying to change pin in ATM. Pin change script is generated and format looks like is OK when checking MasterCard docs.
Our pin change script looks like this: 86158424000210PPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMM where 16 P letters are PIN block sent in DE125 and 16 M letters represents MAC. (I masked them, but below will be used data from example)
With this script all looks ok here from my side. Now i suspect the problem is MAC generation.
To generate MAC we use following HSM commands:
HA (generate TAK (its a random key, every time (every PIN change operation) i call this command, key is different)) - the input is: key = PVK key (U+32Hex symbols under LMK), delimiter = ';', keySchemeTmk = 'U', keySchemeLmk = 'U'; Then the TAK key is received
M6 (generate MAC) - input is: modeFlag = 0, inputFormatFlag = 2, macSize = 1, macAlgorithm = 3, paddingMethod = 0, keyType = '003', key = 'Tak key from HA command', messagelength = '0030', message = '8424000210345755BFDC4F2903A392B3E1229A502C892680' (message is concatenated like in the screenshot above: command header + ApplicationtransactionCounter + ARQC + PIN Block) (message data here is from example in screenshot)
So, when those two commands are executed, i receive 16HEX symbols MAC which exatcly i need. So the script is prepared like this: 8424000210 B3E1229A502C8926 422A8FF11056ACD4: header => 8424000210, pinBlock => B3E1229A502C8926 and MAC => 422A8FF11056ACD4
When i go to ATM and do Pin change, my pin never get changed and i receive reversal message.
Also can anyone explain what are those flags, i'm not sure which ones i should use (command M6):
So the questions are:
Is HSM command M6 correct command to generate MAC for PIN change/unblock script? It requires TAK key while MasterCard docs clearly states that it should be done with SMI key.
Is my config for M6 command is not correct when trying to retrieve MAC hash?
Updated
I managed to get KU command working and it brings me response but the PIN change itself is not successfully completed. Below i will show you what request i generate to the KU command:
{
"mode_flag": "3",
"scheme_id": "1",
"mk_smi": "U25A22A6553A7F68ABACBD1E04BBD8889",
"pan": "7891234567891200",
"integrity_session_data": "55BFDC4F2903A392",
"plaintext_message_data_length": "0018",
"plaintext_message": "8424000210345755BFDC4F2903A392B3E1229A502C892680",
"delimiter": ";",
"confidentiality_session_data": "55BFDC4F2903A392",
"offset": "000F",
"cipher_text_message_data_length": "0008",
"cipher_text_message_data": "B3E1229A502C8926",
"delimiter2": ";",
"source_pin_encryption_key_type": "0",
"source_pin_encryption_key": "UBAAAA3488AA6AA564AAC8AA3AAC1AAA2",
"source_pin_block_format_code": "01",
"destination_pin_block_format_code": "35",
"pan2": "891234567891"
}
Keys and sensitive data is masked so the PAN is used here: 5678912345678912 and sequence number 000. For the first pan parameter 14 last PAN digits used + two last digits from sequence number. For pan2 parameter, only 12 last PAN digits used, with check digit excluded.
Am i using correct Offset flag for replacing PIN block in plaintext data with the new encrypted pin block ?
Answering your question, M6 is not what you should call for script generation. It's purely for message integrity when communicating with acceptance devices or other hosts. That's why there is even no option for derivation of keys required for cards.
For EMV cards there are seperate sets of commands for verification of ARQC, generation of ARPC as well as generation of issuer scripts.
For Issuer scripts generation purpose, please have a look at KY command where you shall supply master keys for integrity and confidentiality as well as other parameters (including PAN, PSN, ATC, etc) that are required for session key derivation. There is a particular mode for PIN change command where PINblock is supplied under ZPK or TPK.
You should check precisely security parameters you have set for your cards as there are different algorithms that may be used for session keys derivation (verify what are your card application settings). Cards may also support different MAC length and you should take care of it as well.
I am fighting the same issue.
I may be wrong but speaking to other folks I was told that KU is the one to use for CVN10.
Now, I was also told to only use KU command as it does everything that is needed.
This means it will translate the new pinblock that is coming in from the ATM using the pin key that is stored on the chip.
The only thing I see is that the destination pinblock you use is 35 which is Europay > MC Pay now, but I think you have to use 34 which is the default for offline clear pin.
I read here that EVM cards will sign some transaction data.
I would like to do this with my card, using my phone, and verify that the signature on the result is correct.
To start, I issued this command ("request APDU"):
00:A4:04:00:0E:32:50:41:59:2E:53:59:53:2E:44:44:46:30:31:00
One of the "Application IDs" was this:
A00000038410
So then I issued this command ("Select Payment application"):
00:A4:04:00:07:A0:00:00:00:03:10:10:00
and it returned this "Processing Options Data Object List (PDOL)":
9F66049F02069F37045F2A02
I read here how to decode this, because I couldn't find the official spec anywhere:
9F6604 - the tag 9f 66 represents the terminal transaction qualifiers
9F0206 - tag 9f 02 stands for authorized amount. The PDOL list must have the amount, authorized, coded into 6h bytes added to it.
9F3704 - tag 9f 37 stands for unpredictable number, thus encode such a number in 4 bytes and add it to the list
and here how to decode this:
5F2A02 - TX currency code
I understand the next step is to run "Get Processing Options" but this is where I got stuck. I tried:
80:A8:00:00:02:83:00:00
80:A8:00:00:12:83:10:01:02:03:04:05:06:07:08:01:02:03:04:05:06:07:08:00
80:A8:00:00:12:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
80:A8:00:00:02:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
All gave back a result of 6D:00 (Instruction code not programmed or invalid).
I tried looking in "emv book 3" and "emv book 4" but neither seem to contain the relevant information.
What do I need to do next in order to make a transaction, sign, and check the result?
Your GPO commands needs to provide the PDOL values requested by the card. The requested tags are:
9F66 - 4 bytes
9F02 - 6 bytes
9F37 - 4 bytes
5F2A - 2 bytes
So the commands needs to provide these in the same order, with expected lengths.
Assuming you want to send the following sample values:
9F66: 11223344
9F02: 112233445566
9F37: 11223344
5F2A: 1122
Your GPO command will look like this:
80A800001283101122334411223344556611223344112200
Where the PDOL data is 11223344112233445566112233441122.
Hope this helps
If PDOL found in response of select application, here you need to pass the value of PDOL tags in GPO command,
can find a very good article Here. hope it helps.
I have empty JavaCOS A40 smartcard and want make it a PKCS PKI card.
I'm going to use it as ssh key and for e-contracts signing. Russia don't provide smartcard-based e-id for citizens like EU countries do. Commercial e-signature providers are selling some sort of password-protected usb drives, that's unsafe to use, because you can easily export private key. Also they sell normal smartcards, but they are really expensive(x10-x20 than empty javacard) and short-living(about 1 year). So i want to make my own PKI card based on RSA algorhitms from javacard.
Now my javacard is in state OP_READY and I don't changed it, because changes are irreversible. It use default key and anyone can upload anything. I use ACR38U reader with pcsc linux driver on Ubuntu and it works as expected, so I used GlobalPlatformPro to upload PKI IsoApplet as default. So GP's output:
java -jar gp.jar -list
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
ISD: A000000003000000 (OP_READY)
Privs: SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement
APP: F276A288BCFBA69D34F31001 (SELECTABLE)
Privs: CardReset
PKG: F276A288BCFBA69D34F310 (LOADED)
Version: 1.0
Applet: F276A288BCFBA69D34F31001
cardpeek successfully connects to it and I can send low-level commands to applet
But when I try to connect to card and applet using opensc prober to see Answer-To-Request(ATR), it fails opensc-tool --reader 0 --atr. See maximum debug info
Shortened version:
opensc-tool --reader 0 --atr -vv
Connecting to card in reader ACS ACR 38U-CCID 00 00...
0x7fc849e7e740 22:17:14.634 [opensc-tool] card.c:200:sc_connect_card: called
0x7fc849e7e740 22:17:14.634 [opensc-tool] card-entersafe.c:138:entersafe_match_card: called
Failed to connect to card: Card command failed
0x7fc849e7e740 22:17:14.797 [opensc-tool] ctx.c:870:sc_release_context: called
According to manufacturer info, card is supporting T=0 over ISO7816, but opensc tries to communicate with T=1. So how I can fix this?
Seems, that opensc tools are not customizable. I need to use pkcs15-crypt, but it can't connect. May I change drivers, recompile opensc with patches, or use another utility? How another ways I can use to work with OpenPGP for example?
Your problem is certainly not with the transport protocol because it communicates an APDU with the card. When looking at the logging it seems to incorrectly guess from the ATR that the card is an epass2003:
0x7f175a21e740 22:14:13.904 [opensc-tool] card.c:287:sc_connect_card: matched: epass2003
then execute a command to it:
0x7f175a21e740 22:14:13.904 [opensc-tool] apdu.c:378:sc_single_transmit: CLA:0, INS:CA, P1:1, P2:86, data(0) (nil)
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:283:pcsc_transmit: reader 'ACS ACR 38U-CCID 00 00'
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:284:pcsc_transmit:
Outgoing APDU (5 bytes):
00 CA 01 86 00 .....
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:212:pcsc_internal_transmit: called
0x7f175a21e740 22:14:13.912 [opensc-tool] reader-pcsc.c:293:pcsc_transmit:
Incoming APDU (2 bytes):
6D 00 m.
0x7f175a21e740 22:14:13.912 [opensc-tool] apdu.c:390:sc_single_transmit: returning with: 0 (Success)
0x7f175a21e740 22:14:13.912 [opensc-tool] apdu.c:543:sc_transmit: returning with: 0 (Success)
0x7f175a21e740 22:14:13.912 [opensc-tool] card.c:459:sc_unlock: called
0x7f175a21e740 22:14:13.912 [opensc-tool] reader-pcsc.c:662:pcsc_unlock: called
0x7f175a21e740 22:14:13.921 [opensc-tool] card-epass2003.c:189:epass2003_check_sw: Instruction code not supported or invalid
0x7f175a21e740 22:14:13.921 [opensc-tool] card-epass2003.c:1118:get_data: get_data failed: -1204 (Unsupported INS byte in APDU)
Now this command is executed over the communication channel in T=1 (it's very unlikely that the card just supports T=0 if it also supports T=CL, because T=CL and T=1 are very much alike - at the higher level). Not only that, it correctly returns a result, even if that is higher level error condition: 6D00 meaning instruction not supported.
This leads to the high lever error condition:
Failed to connect to card: Card command failed
which is slightly misleading, because it certainly connected to the card, it just wasn't able to get any data from it using a GET DATA command. This isn't that strange because it didn't first select any applet and GET DATA (with INS-truction CA) is not likely to be present in the root folder / applet.
TL;DR your connection is fine, now start programming it by issuing GlobalPlatform card manager commands to it. If possible use a different tool or get opensc tools to skip the identification phase / initial commands to it.
IsoApplet and OpenPGP are two different world. For OpenPGP support, look at either SmartPGP by ANSSI-FR on github or ykneo-openpgp (also on Github).
For signatures, you also do not need pkcs15-crypt but should work via PKCS#11 library instead.
For this specific reason - the card being matched as epass, disable the epass driver in opensc.conf.
I have kannel SMPP (kannel.org) and receive SMS statuses by param: %d
And here is table:
16 = not delivered to smsc
8 = you submitted to smsc. ie smsc tell
kannel he has the msg
4 = msg is in smsc queue. ie smsc tell kannel he queued the msg in its queue.
2 = failed 1 = delivered to phone
But here is very low information. How I can receive more information about (wrong number or something like what)? Now is just failed and whats all, if we want to know why failed we must ask our partners support.
More detailed information on delivery error you can fetch from the following sources:
network_error_code TLV (0x0423) - see p. 5.3.2.31 of SMPP v3.4 specification
text part of DLR message (%A in dlr-url)
command_status in case of rejection (represented as "NACK/$code"
Example of text part in DLR:
id:0832095221 sub:001 dlvrd:000 submit date:1203311115 done date:1204010436 stat:UNDELIV err:011 text:some text here
Here you can see 011 error code in undeliverable message.
However there are many vendor specific issues you need to discover with each new SMSC. And no strict requirements in SMPP specification to information to represented in DLR.
For your DLR URL add this:
dlr_mask=31
dlr_url=....?answer=%A&status=%d
Where DLR bitmask means:
1: Received by phone
2: Failure to deliver to phone
4: Queued for delivery
8: Accepted by other SMSC
16: Rejected by other SMSC
If you get a 16, or your get a 2 it'll look like this:
status=<2 or 16 here>
answer=NACK//
The get a table mapping hex_code to its vendor-specific meaning from the carrier