I Have successfully generated a ARQC by fulfilling the PDOL requirements as requested by the ICC (VISA). I would like to force all transactions with online PIN validation, irrespective of floor limits, pin try limits etc.
Do I need to still do another generate AC command or is the below sufficient to submit for online processing ?
Response Message Template Format 2 [77]:
Application Interchange Profile (AIP) [82]:
Data (Binary): 20 00
Bit flags set:
1Bxb8: 0 - RFU
1Bxb7: 0 - Off-line SDA is not supported
1Bxb6: 1 - Off-line DDA is supported
1Bxb5: 0 - Cardholder verification is not supported
1Bxb4: 0 - Terminal risk management not required
1Bxb3: 0 - Issuer Authentication not supported
1Bxb2: 0 - RFU
1Bxb1: 0 - CDA not supported
2Bxb8: 0 - MSD not supported (Contactless value)
2Bxb7: 0 - RFU
2Bxb6: 0 - RFU
2Bxb5: 0 - RFU
2Bxb4: 0 - RFU
2Bxb3: 0 - RFU
2Bxb2: 0 - RFU
2Bxb1: 0 - RFU
Application File Locator (AFL) [94]:
Data (Binary): 10 02 02 00 10 05 06 00 10 03 03 00
Track 2 Equivalent Data [57]:
Data (Binary): pp pp pp pp pp pp pp pp D2 20 72 26 00 00 00 03 43 00 0F
Cardholder Name [5F20]:
Data (Binary): 20 2F
Data (ASCII): /
Issuer Application Data (IAD) [9F10]:
Data (Binary): 06 01 11 03 A0 00 00 0F 83 00 00 00 00 00 00 00 00 00 00 E0 68 76 3A
Application Cryptogram (AC) [9F26]:
Data (Binary): FB 61 6D 9B 3F FC 00 7E
Cryptogram Information Data (CID) [9F27]:
Data (Binary): 80
Application Transaction Counter (ATC) [9F36]:
Data (Binary): cc cc
Card Transaction Qualifiers (CTQ) [9F6C]:
Data (Binary): 3E 40
Bit flags set:
1Bxb8: 0 - Online PIN not Required
1Bxb7: 0 - Signature Not Required
1Bxb6: 1 - Go Online if Offline Data Authentication Fails and Reader is online capable.
1Bxb5: 1 - Switch Interface if Offline Data Authentication fails and Reader supports VIS.
1Bxb4: 1 - Go Online if Application Expired
1Bxb3: 1 - Switch Interface for Cash Transactions
1Bxb2: 1 - Switch Interface for Cashback Transactions
1Bxb1: 0 - RFU
2Bxb8: 0 - Consumer Device CVM not Performed
2Bxb7: 1 - Card supports Issuer Update Processing at the POS
2Bxb6: 0 - RFU
2Bxb5: 0 - RFU
2Bxb4: 0 - RFU
2Bxb3: 0 - RFU
2Bxb2: 0 - RFU
2Bxb1: 0 - RFU
Customer Exclusive Data (CED) [9F7C]:
Data (Binary): 00 00 00 00
Form Factor Indicator (qVSDC) [9F6E]:
Data (Binary): 20 70 00 00
According the provided reply the CTQ Tag 0x9F6C there is no Online PIN, Signature or CDCVM required by card. Card Application expired and require to get final authorisation/approval online.
To force card to request Online PIN for all transactions you may set Floor limit to zero and exclude all other CVMs from Terminal Transaction Qualifiers (TTQ) Tag 0x9F66.
Up to your terminal configuration preferences to support Signature or CDCVM.
Related
I am trying to implement a SSL client into my IoT project. I have copied the SSL_Client example I found in STM32Cube_FW_F7_V1.15.0 into my project and was able to compile succesfully. However the SSL handshake fails with -0x7780 MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE. I attach the console debug output:
. Seeding the random number generator... ok
. Loading the CA root certificate ... ok (1 skipped)
. Connecting to tcp/www.google.de/443... ok
. Setting up the SSL/TLS structure... ok
. Performing the SSL/TLS handshake...=> handshake
client state: 0
=> flush output
<= flush output
client state: 1
=> flush output
<= flush output
=> write client hello
client hello, max version: [3:3]
dumping 'client hello, random bytes' (32 bytes)
0000: 88 d9 c4 b1 4f 82 ef a2 74 80 5c 6e 3f c4 29 ca ....O...t.\n?.).
0010: a4 8d 61 2b f6 37 ec 93 39 cb 7d d0 39 5a 67 9b ..a+.7..9.}.9Zg.
client hello, session id len.: 0
dumping 'client hello, session id' (0 bytes)
client hello, add ciphersuite: c02b
client hello, add ciphersuite: c031
client hello, add ciphersuite: c02d
client hello, add ciphersuite: 00a8
client hello, got 4 ciphersuites (excluding SCSVs)
adding EMPTY_RENEGOTIATION_INFO_SCSV
client hello, compress len.: 1
client hello, compress alg.: 0
client hello, adding server name extension: mbed TLS Server 1
client hello, adding signature_algorithms extension
client hello, adding supported_elliptic_curves extension
client hello, adding supported_point_formats extension
client hello, adding encrypt_then_mac extension
client hello, adding extended_master_secret extension
client hello, total extension length: 62
=> write handshake message
=> write record
output record: msgtype = 22, version = [3:3], msglen = 117
dumping 'output record sent to network' (122 bytes)
0000: 16 03 03 00 75 01 00 00 71 03 03 88 d9 c4 b1 4f ....u...q......O
0010: 82 ef a2 74 80 5c 6e 3f c4 29 ca a4 8d 61 2b f6 ...t.\n?.)...a+.
0020: 37 ec 93 39 cb 7d d0 39 5a 67 9b 00 00 0a c0 2b 7..9.}.9Zg.....+
0030: c0 31 c0 2d 00 a8 00 ff 01 00 00 3e 00 00 00 16 .1.-.......>....
0040: 00 14 00 00 11 6d 62 65 64 20 54 4c 53 20 53 65 .....mbed TLS Se
0050: 72 76 65 72 20 31 00 0d 00 0a 00 08 04 03 04 01 rver 1..........
0060: 03 03 03 01 00 0a 00 04 00 02 00 17 00 0b 00 02 ................
0070: 01 00 00 16 00 00 00 17 00 00 ..........
=> flush output
message length: 122, out_left: 122
ssl->f_send() returned 122 (-0xffffff86)
<= flush output
<= write record
<= write handshake message
<= write client hello
client state: 2
=> flush output
<= flush output
=> parse server hello
=> read record
=> fetch input
in_left: 0, nb_want: 5
in_left: 0, nb_want: 5
ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
<= fetch input
dumping 'input record header' (5 bytes)
0000: 15 03 03 00 02 .....
input record: msgtype = 21, version = [3:3], msglen = 2
=> fetch input
in_left: 5, nb_want: 7
in_left: 5, nb_want: 7
ssl->f_recv(_timeout)() returned 2 (-0xfffffffe)
<= fetch input
dumping 'input record from network' (7 bytes)
0000: 15 03 03 00 02 02 28 ......(
got an alert message, type: [2:40]
is a fatal alert message (msg 40)
mbedtls_ssl_handle_message_type() returned -30592 (-0x7780)
mbedtls_ssl_read_record() returned -30592 (-0x7780)
<= handshake
failed
! mbedtls_ssl_handshake returned -0x7780
I am thankfull for every hint in the right direction.
client hello, adding server name extension: mbed TLS Server 1
The client is using the SNI extension to indicate that it wants to talk to mbed TLS Server 1. The server on port 443 of www.google.de can respond as www.google.de, google.de and a bunch of other names that Google controls, but it does know about mbed TLS Server 1, so it sends a fatal alert indicating that it cannot complete the handshake.
You can use the sample client as is to talk to the sample server whose source code should be next to it. To contact another server, you need to change or remove the call to mbedtls_ssl_set_hostname.
I want to establish a tls connection between my sim card and a server in TLS-PSK mode. to achive this, as far as I understood, First I have to send a push command to open a BIP channel, then establish a CAT_TP link by sending another push command and then sim card will start the TLS handshake. So first I want to send a push command to my sim card to open a BIP channel. To do this, the push command will be OPEN CHANNEL command. But first I'm testing this process by sending the OPEN CHANNEL command to sim card via sim card reader to see how it works. I have a sample file which I'm following that first sends an envelope SMS-PP with the following content:
81488346 \
84 44\ ;Connection parameter tag
81 03 014001\ ;Command details TLV
82 02 8182\ ;Device identities TLV
35 01 03\ ;Bearer description TLV: default
39 02 0514\ ;Buffer size TLV
47 14 13696E7465726E65742D656E7472657072697365\ ;Network Access Name
0D 07 xxxxxxxxxxxxxx\ ;login name
0D 07 xxxxxxxxxxxxxx\ ;password
3C 03 021964\ ; UICC/terminal interface port number
3E 05 xxxxxxxxxx ;IP address
in sample file it ciphers the above content by sim card's keys and it's RAM TAR value and sends the ciphered data by an envelope command like this:
Command : 80 C2 00 00 8A
Input Data : D1 81 87 02 02 82 81 06 02 80 01 8B 7D 40 05 81
: 12 50 F3 96 F6 22 22 22 22 22 22 22 6D 02 70 00
: 00 68 15 16 39 12 12 00 00 01 F0 BD C0 49 B4 0C
: EB A9 7C 4B 04 32 17 BE A7 2F DA AC 70 93 36 73
: 83 FD AC 64 CA 9B 34 9C 2B E6 31 24 A0 D5 11 09
: 00 3E E3 F5 43 4B 55 77 98 E5 08 40 A4 CE A9 52
: 3E E1 38 6B 44 AC 73 1E 3B CD 49 32 92 B2 C3 22
: 25 02 68 90 FD F5 06 23 97 0D BD 5B 1D DE 25 F1
: FD 4C 75 C8 37 AC B0 15 05 25
Then it fetches the push sms via a FETCH command and after that get the terminal response with TERMINAL RESPONSE command to see if everything went ok. and finally fetches the open channel with the FETCH command and it says once OPEN CHANNEL is done, card sends CLIENT HELLO to the server to start the TLS handshake.
Now I want to implement this but at the first step, where I should send the envelope, I expect to get 9146 as status word which means everything was ok. but I get 6200 which means "State of non-volatile memory is unchanged".
Why do I get this respnse? And basically what is the proper way to open a BIP channel and then stablish a CAT-TP link?
You should first send the TERMINAL PROFILE command. With this command, you'll let the UICC know what the terminal is capable of. In this command, you should indicate that the terminal is capable of handling PROACTIVE commands. You can read more about this in ETSI TS 102223
How can I determine where the MTI start in an ISO 8583 message?
00 1F 60 00 05 80 53 08 00 20 20 01 00 00 80 00 00 92 00 00 00 31 07 00 05 31 32 33 34 31 32 33 34
In that message 00 1F is the length, and 60 00 05 80 53 is the TPDU. (Those aren't part of ISO8583). 08 00 is the MTI. The next 8 bytes are the primary bitmap.
You can buy a copy of the ISO8583 specification from ISO. There is an introduction on wikipedia
position of the MTI is network specific, and should be explained in their technical specifications document.
You can eyeball the MTI by looking for values such as 0100, 0110, 0220, 0230, 0800, etc. in the first 20 bytes, and the are typically followed by 8 to 16 bytes of BMP data
your data shows MTI = 800 with a bitmap = 20 20 01 00 00 80 00 00
That means the following fields are present, 3,11,24,41, with DE 3 (PRoc code) = 920000, DE 11 (STAN) = 003107, and the remaining is shared among 24 and 41, I am not sure about their sizes
In this message a 2 byte header length is used:
00 1F
But some Hosts also use 4 byte header length for ISO 8583 messages. So you can not generalize it, it depends on what you have arranged with the sending Host.
We have 5 customers running the same WebService from Domino
This weekend we updated the customers servers with Domino 9.01. FP2 and the Poodle fixpack to be able to run TLS 1.0 incomming and outgoing.
4 Customers works perfect
1 Customer gets SSL errors for the outgoing Webservice (same errors as before we updated the servers), the incomming is working for TLS so we guess the updates for Poodle have worked as intended.
After setting som DEBUG_SSL parameters for one working and the failing server we got this logs
The failing row is
S_Read> nti_done return 0 bytes rc = 9
instead of intended
S_Read> nti_done return 5 bytes rc = 0
SSL_RCV> 00000000: 16 03 01 00 2E
I have searched google and nothing is there to understand what is missing
My guess is there is some problem with negotiating the cipher, but why and what to do for solving this matter.
I know there is some smart people out there ;-)
Log from failing server handshake
int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]
SSL_Handshake> Enter
SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
SSLAdvanceHandshake Enter> Processed : 0 State: 4 (HandshakeClientIdle)
SSLAdvanceHandshake Enter> Processed : SSL_hello_request
SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeClientHello
SSLEncodeClientHello> We offered SSL/TLS version TLS1.0 (0x0301)
SSLAdvanceHandshake Exit> State : 5 (HandshakeServerHello)
S_Write> Enter len = 58
SSL_Xmt> 00000000: 16 03 01 00 35 01 00 00 31 03 01 54 A5 85 B7 4D '....5...1..T%.7M'
SSL_Xmt> 00000010: 15 80 11 80 C7 47 4D 1D 1D B1 89 5F F6 94 18 73 '....GGM..1._v..s'
SSL_Xmt> 00000020: C6 D3 7D 6A 15 92 A9 57 48 19 32 00 00 0A 00 2F 'FS}j..)WH.2..../'
SSL_Xmt> 00000030: 00 35 00 05 00 0A 00 04 01 00 '.5........'
S_Write> Switching Endpoint to sync
S_Write> Posting a nti_snd for 58 bytes
SSL_EncryptData> SSL not init exit
S_Write> Switching Endpoint to async
SSL_EncryptDataCleanup> SSL not init exit
S_Write> nti_done return 58 bytes rc = 0
S_Write> Exit, wrote 58 bytes
S_Read> Enter len = 5
S_Read> Switching Endpoint to sync
S_Read> Posting a nti_rcv for 5 bytes
SSL_RcvSetup> SSL not init exit
S_Read> Switching Endpoint to async
S_Read> nti_done return 0 bytes rc = 9
S_Read> nti_done return 0 bytes rc = 9 Event = 0x100
SSLSendAlert> Sending an alert of 0x0 (close_notify) level 0x2 (fatal)
SSL_Handshake> Changing SSL status from -6989 to -5000 to flush write queue
SSL_Handshake> After handshake state= 2 Status= -5000
SSL_Handshake> Exit Status = -5000
int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]
...
Log from working server handshake
int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]
SSL_Handshake> Enter
SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
SSLAdvanceHandshake Enter> Processed : 0 State: 4 (HandshakeClientIdle)
SSLAdvanceHandshake Enter> Processed : SSL_hello_request
SSLAdvanceHandshake calling SSLPrepareAndQueueMessage> SSLEncodeClientHello
SSLEncodeClientHello> We offered SSL/TLS version TLS1.0 (0x0301)
SSLAdvanceHandshake Exit> State : 5 (HandshakeServerHello)
S_Write> Enter len = 58
SSL_Xmt> 00000000: 16 03 01 00 35 01 00 00 31 03 01 54 A5 89 B3 A0 '....5...1..T%.3 '
SSL_Xmt> 00000010: 2B 75 D1 E9 D4 81 87 C3 5D 91 45 84 6A E2 47 9D '+uQiT..C].E.jbG.'
SSL_Xmt> 00000020: 76 BE 14 A8 A6 10 1C 06 FB 7D 8B 00 00 0A 00 2F 'v>.(&...{}...../'
SSL_Xmt> 00000030: 00 35 00 05 00 0A 00 04 01 00 '.5........'
S_Write> Switching Endpoint to sync
S_Write> Posting a nti_snd for 58 bytes
SSL_EncryptData> SSL not init exit
S_Write> Switching Endpoint to async
SSL_EncryptDataCleanup> SSL not init exit
S_Write> nti_done return 58 bytes rc = 0
S_Write> Exit, wrote 58 bytes
S_Read> Enter len = 5
S_Read> Switching Endpoint to sync
S_Read> Posting a nti_rcv for 5 bytes
SSL_RcvSetup> SSL not init exit
S_Read> Switching Endpoint to async
S_Read> nti_done return 5 bytes rc = 0
SSL_RCV> 00000000: 16 03 01 00 2E '.....'
S_Read> Exit, read 5 bytes
S_Read> Enter len = 46
S_Read> Switching Endpoint to sync
S_Read> Posting a nti_rcv for 46 bytes
SSL_RcvSetup> SSL not init exit
S_Read> Switching Endpoint to async
S_Read> nti_done return 46 bytes rc = 0
SSL_RCV> 00000000: 02 00 00 2A 03 01 54 7C 9D 24 4C B4 AD 62 4E 35 '...*..T|.$L4-bN5'
SSL_RCV> 00000010: 4C C3 B4 AB 34 6D 7D CB 8F 6B CC 80 00 FE 4C 4A 'LC4+4m}K.kL..~LJ'
SSL_RCV> 00000020: 77 87 CD 2E DF 98 04 10 13 29 0B 00 2F 00 'w.M._....)../.'
S_Read> Exit, read 46 bytes
SSLProcessProtocolMessage> Record Content: 22
SSLProcessHandshakeMessage Enter> Message: 2 State: 5 (HandshakeServerHello) Key Exchange: 0 Cipher: 0x0000 (Unknown Cipher)
SSLProcessHandshakeMessage Enter> Message: SSL_server_hello
SSLProcessServerHello> Server chose SSL/TLS version TLS1.0 (0x0301)
SSLProcessHandshakeMessage Exit> Message: 2 State: 5 (HandshakeServerHello) Key Exchange: 1 Cipher: 0x002F (RSA_WITH_AES_128_CBC_SHA)
SSLAdvanceHandshake Enter> Processed : 2 State: 5 (HandshakeServerHello)
SSLAdvanceHandshake Enter> Processed : SSL_server_hello
SSLAdvanceHandshake Exit> State : 8 (HandshakeCertificate)
SSL_Handshake> After handshake state= 8 Status= -5000
SSL_Handshake> Exit Status = -5000
int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]
SSL_Handshake> Enter
SSL_Handshake> Current Cipher 0x002F (RSA_WITH_AES_128_CBC_SHA)
S_Read> Enter len = 5
S_Read> Switching Endpoint to sync
S_Read> Posting a nti_rcv for 5 bytes
SSL_RcvSetup> SSL not init exit
S_Read> Switching Endpoint to async
S_Read> nti_done return 5 bytes rc = 0
SSL_RCV> 00000000: 16 03 01 0E 9D '.....'
S_Read> Exit, read 5 bytes
S_Read> Enter len = 3741
....
/Stefan
PS: Here is the Java errors that come sfter the hand shake error
Error connecting to 'xxxxx' on port '443', SSL IO error. Remote session no longer responding.
at lotus.domino.axis.InternalFault.makeFault(Unknown Source)
at lotus.domino.axis.transport.http.HTTPSender.invoke(Unknown Source)
at lotus.domino.axis.strategies.InvocationStrategy.visit(Unknown Source)
at lotus.domino.axis.SimpleChain.doVisiting(Unknown Source)
at lotus.domino.axis.SimpleChain.invoke(Unknown Source)
at lotus.domino.axis.client.AxisClient.invoke(Unknown Source)
at lotus.domino.axis.client.Call.invokeEngine(Unknown Source)
at lotus.domino.axis.client.Call.invoke(Unknown Source)
at lotus.domino.axis.client.Call.invoke(Unknown Source)
at lotus.domino.axis.client.Call.invoke(Unknown Source)
at lotus.domino.axis.client.Call.invoke(Unknown Source)
at lotus.domino.websvc.client.Call.invoke(Unknown Source)
I'm trying to read the xref table of a pdf version >= 1.5.
the xref table is an object:
58 0 obj
<</DecodeParms<</Columns 4/Predictor 12>>/Filter/FlateDecode/ID[<CB05990F613E2FCB6120F059A2BCA25B><E2ED9D17A60FB145B03010B70517FC30>]/Index[38 39]/Info 37 0 R/Length 96/Prev 67529/Root 39 0 R/Size 77/Type/XRef/W[1 2 1]>>stream
hÞbbd``b`:$AD`Ì ‰Õ Vˆ8âXAÄ×HÈ$€t¨ – ÁwHp·‚ŒZ$ìÄb!&F† .#5‰ÿŒ>(more here but can't paste)
endstream
endobj
as you can see
/FlatDecode
/Index [38 39], that is 39 entries in the stream
/W [1 2 1] that is each entry is 1 + 2 + 1 = 4 bytes long
/Root 39 0 R that is root object is number 39
BUT :
the decompressed stream is 195 bytes long (39 * 5 = 195). So the length of an entry is 4 or 5.
Here is the first inflated bytes
02 01 00 10 00 02 00 02 cd 00 02 00 01 51 00 02 00 01 70 00 02 00 05 7a 00 02
^^
if entry length is 4 then the root entry is a free object (see the ^^) !!
if the entry is 5: how to interpret the fields of one entry (reference is implicitly made to PDF Reference, chapter 3.4.7 table 3.16 ) ?
For object 38, the first of the stream: it seems, as it is of type 2, to be the 16 object of the stream object number 256, but there is no object 256 in my pdf file !!!
The question is: how shall I handle the 195 bytes ?
A compressed xref table may have been compressed with one of the PNG filters. If the /Predictor value is set to '10' or greater ("a Predictor value greater than or equal to 10 merely indicates that a PNG predictor is in use; the specific predictor function used is explicitly encoded in the incoming data")1, PNG row filters are supplied inside the compressed data "as usual" (i.e., in the first byte of each 'row', where the 'row' is of the width in /W).
Width [1 2 1] plus Predictor byte:
02 01 00 10 00
02 00 02 cd 00
02 00 01 51 00
02 00 01 70 00
02 00 05 7a 00
02 .. .. .. ..
After applying the row filters ('2', or 'up', for all of these rows), you get this:
01 00 10 00
01 02 ed 00
01 03 3e 00
01 04 ae 00
01 09 28 00
.. .. .. ..
Note: calculated by hand; I might have made the odd mistake here and there. Note that the PNG 'up' filter is a byte filter, and the result of the "up" filter is truncated to 8 bits for each addition.
This leads to the following Type 1 XRef references ("type 1 entries define objects that are in use but are not compressed (corresponding to n entries in a cross-reference table)."):2
#38 type 1: offset 10h, generation 0
#39 type 1: offset 2EDh, generation 0
#40 type 1: offset 33Eh, generation 0
#41 type 1: offset 4AEh, generation 0
#42 type 1: offset 928h, generation 0
1 See LZW and Flate Predictor Functions in PDF Reference 1.7, 6th Ed, Section 3.3: Filters.
2 As described in your Table 3.16 in PDF Ref 1.7.