I received the the following IAD after processing the GPO command, my question then, how is the 9F10 EMV token constructed? Here is the token.
06010A03A020000F04000000000000000000006232E4F9
I am required to send only the CVR portion to the acquiring switch.
Looking at the cryptogram version I assume this is from a Visa card. The TLV is 9F10 17 06010A03A020000F04000000000000000000006232E4F9 ?
17 is the total length of the data
06 is the length of issuer descretionary data
01 is derivation key index
0A is the cryptogram version (10 in this case ).
03 Length of CVR
A02000 is the CVR here
From EMV 4.3 Book 3 Common Core Definitions, Application Specification, November 2011, Page 206, C7.2
The CVR has a fixed length of 5 bytes (10 hexadecimals characters) that are the bytes 4-8 included of Issuer Application Data, EMV tag 9F10.
The 3 first bytes of 9F10 being the following.
b1 the length
b2 derivation key index
b3 the cryptogram version
It seems however that the format of this field might vary between schemes.
Related
I try to create field 55 and send it to bank host for make payment. I'm read all data find (by Apple Pay VISA, token) and create field 55 like this:
9F26 Application Cryptogram: 5CBD1E2494A6DE86 - Get from card
9F27 Cryptogram Information Data: 80 - Get from card
9F10 Issuer Application Data: 1F4A0132A0000000001003027300000000400000000000000000000000000000 - Get from card
9F37 Unpredictable Number: 00002352 - generate it and use in GPO requeste
9F36 Application Transaction Counter (ATC): 029B - Get from card
95 Terminal Verification Results: 0000000000 - Static data
9A Transaction Date: 210805 - Set it myself
9C Transaction Type: 00 - Static data
9F02 Amount, Authorised (Numeric): 000000000100 - Set it myself
5F2A Transaction Currency Code: 0980 - Static data
5F34 Application Primary Account Number (PAN) Sequence Number: 00 - Get from card
82 Application Interchange Profile: 0040 - Get from card
9F1A Terminal Country Code: 0804 - Static data
9F03 Amount, Other (Numeric): 000000000000 - Static data
9F33 Terminal Capabilities: E0F8C8 - Static data
4F Application Identifier (AID) – card: A0000000031010 - Get from card
9F35 Terminal Type: 22 - Static data
84 Dedicated File (DF) Name: A0000000031010 - Get from card
9F6E Unknown tag: 23880000 - Get from card
When I send it and track2 to bank I get response error with code 100 - Decline
and get push-message to phone that transaction was decline.
How I understand it's answer by card issuing bank. Can anyone help what can be trouble? May be incorrect field 55 or can be some problems on the host side of the acquirer bank (then tell me what could be?...).
Please, help! Thanks!
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 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
I'm writing an web server with Lisp to handler HTTPS request. I followed TLS 1.2 and already completed the handshake process. The Cipher Suite I chose is TLS_RSA_WITH_RC4_128_SHA. I already calculated client_write_MAC_secret, server_write_MAC_secret, client_write_key, server_write_key. These keys seems are correct, because I can decrypt "Finished" message from browser and validate the data inside. I also validate the HMAC of the record layer. Then I send a "Change Cipher Spec" and "Finished" from server. So far everything seems working fine.
Then I got the message from browser start with #(23 3 3 1 61 ...). 23 means it's an application data. #(3 3) means TLS 1.2. #(1 61) means length is 256+61=317 which is correct because the data left is really 317 bytes long. Here comes my question: I decrypted these 317 bytes with RC4 using the "client_write_key" then I got data like #(148 104 81 182 67 111 28 201 202 50 207 57 126 209 19 ...) which can't be converted to text. I thought I should get something like GET / HTTP/1.1. What do I get wrong?
Thanks.
RC4 is a stream cipher and, according to RFC 5246, section 6.2.3.1, "For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet."
So, the first record you decrypt is the FINISHED message and the first application data you decrypt should be with the RC4 state as it was left after decrypting the FINISHED message.
when I send an API ND command to a remote endpoint I get ???
When I send an API ND command from a VB program using the following packet;
7E 00 05 08 01 4E 44 00 64
I get;
7E 05 3F 14 E4 41 3F
Its a response -- but not as I know it. Neither the checksum "3F" or command length "05" are comprehensible to me. On the other hand if I wait for more bytes by setting "Serialport1.ReceivedBytesThreshold" (threshold: 10 bytes in buffer > event is fired) to 10 the "SerialPort1.ReadExisting()" statement times out. Any suggestions for decoding? Both coordinator and endpoint are XBEE PRO S2Bs.
I don't think it makes sense to send ATND as a remote AT command, and it will probably be ignored on the remote node, or trigger node discovery at that node with the responses staying local.
It looks like your response is possibly dropping null bytes (0x00), like the MSB of length, and one more in the packet itself. I'm not familiar with a frame type of 0x3F though -- is it documented for that XBee module you're using?
After a node discovery, you should see multiple AT Response frames (type 0x88?) come back over some time (based on ATNT, I believe), until you get one with a short payload (indicating discovery is complete).