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.
Related
I'm learning about POP3 by reading RFC 1939.
The description of the RETR command says the following:
Possible Responses:
+OK message follows
-ERR no such message
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
What does "120 octets" refer to? Is this optional information about the message that may or may not be included, and if so, is "message follows" not required (as specified under "Possible Responses")?
What does "120 octets" refer to? Is this optional information about the message that may or may not be included
Correct, the "120 octets" is optional informational text but is not required text nor can the number of octets be used as definitive for calculating the end of the message data.
and if so, is "message follows" not required (as specified under "Possible Responses")?
That's why it was stated to be a "possible response" ;-)
Basically, all you can really use from that first line is the first token which will be "+OK" or "-ERR". Everything after that is informational text that may be a helpful when debugging, but not guaranteed to be useful for your code to try and interpret.
I would argue that if it is of the form "# octets", you might be able to use it to show progress as you read data, but that's about the best you can do.
Even so, I would probably recommend using the octet value from the LIST command instead.
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 want to define a Ring Group that, when called, rings one extension and one external number (mobile phone). What is the best way to achieve that?
Right now only the extension is called. So just entering an external number in the Destination field does not work, the logs say
[NOTICE] switch_cpp.cpp:1376 [ring groups][call forward all] user_exists id <mobileno> <domainname>
and later
[DEBUG] switch_ivr_originate.c:3865 Originate Resulted in Error Cause: 27 [DESTINATION_OUT_OF_ORDER]
It will check all calls using the dialplan to see if the destination is a local number for an external number it should say user_exists false every time.
This [DESTINATION_OUT_OF_ORDER] indicates that it may not have found a matching outbound route that matches the number of digits of the external phone number. Or it may mean that your carrier rejected the call maybe didn't like the caller ID that was sent. Easiest thing to try is attempt it with an outbound rout to different carrier.
In case you weren't aware FusionPBX 4.4 was release on 5 April 2018. Instructions to upgrade are post on docs.fusionpbx.com. Search term upgrade (version upgrade).
I was wondering if anyone could help me understand difference between ISO 8583 Field 22 i.e. POS Entry Mode. I already know that:
52 means ICC Card
80 in case of fallback
But what I want to know is difference between
22 (Magnetic Stripe)
and 90
Can anyone help me on this?
The length of Field 22 usually 3-digits (or 4-digits in case it is BCD packed into two Bytes) in protocols based on ISO 8583:1987 or 12-digits in case protocols based on ISO 8583:1993 version. Customized protocols could use different sub-fields content and values meaning behind.
While you use short values in the requested question, I guess, your Field 22 based on ISO 8583:1987 version and you lost the leading and/or ending zero. So, your sample values becomes 3 digits length - 052, 800, 022, and 090 or 900.
Usually the 3-digits Field 22 splited into two sub-fields:
Position 1 and 2 - Personal Account Number (PAN) Entry (or capability);
Position 3 - Personal Identification Number (PIN) Entry (or capability);
Here are the possible interpretations:
02 - PAN auto-entry via magnetic stripe, track data is not required, 2 - no PIN.
05 - PAN auto-entry via chip, 2 - no PIN.
09 - E-Commerce, 0 - unknown PIN capability.
80 - Fallback to magnetic stripe, 0 - unknown PIN capability.
90 - PAN auto-entry via magnetic stripe, track data should be transmitted within the authorization request, 0 - unknown PIN capability.
etc.
90 used in case track data present in the ISO 8583 request message, 02 - if, for same reason, acquirer or terminal device not qualified to transfer track data in the request messages.
Depending of protocol requirements could be exceptions with Field 22 values. It is usually checked during the terminal device and communication interface certifications.
I will elaborate few things here. From above comments I can see that 09 is for E commerce transactions,but as per my knowledge for E commerce transactions we should use PAN Entry mode as 01(manual entry). Because for card not present transactions entry mode has always in manually.
POS Entry mode says whether the particular transaction is E commerce or POS. The possible values are :
01 Manual entry
02 Magnetic Stripe,track 2 data will ignore
05 Smart card,track 2 data required
90 Magnetic stripe no track 2 data
91 contactless card
95 Smart card , track2 data not required
Thanks share your ideas on this