Parsing Data Element 55 for Chip Card

[wshehab]

hi,

i am trying now to unpack the the message that i received from POS terminal
with my jpos server.
the message unpacked till de55. how can i create a special packager for de55
because there are some variable length tag inside it.the hex dump message
is:

0000 04 00 32 20 44 81 20 E0 82 08 00 00 00 00 00 00 ..2 D. .........
0010 00 09 00 12 31 11 56 12 00 00 00 59 99 00 52 00 ....1.V....Y..R.
0020 10 00 00 40 29 74 34 55 79 72 41 12 20 08 57 D1 ...@)t4UyrA. .W.
0030 01 12 01 81 74 00 86 3F 30 30 30 30 31 30 32 20 ....t..?0000102
0040 30 30 30 34 32 32 30 30 30 30 30 31 30 30 32 4D 000422000001002M
0050 45 52 43 48 41 4E 54 20 54 45 53 54 20 53 48 4C ERCHANT TEST SHL
0060 55 4D 42 45 52 47 45 41 43 48 52 41 46 49 45 48 UMBERGEACHRAFIEH
0070 20 20 20 20 4C 42 4E 08 40 79 9F 26 08 95 F4 01 LBN.@y.&....
0080 75 54 9D F2 1E 9F 27 01 80 9F 10 12 01 11 A0 80 uT....'.........
0090 03 24 04 00 43 22 68 B6 AE 17 F1 76 D0 14 9F 37 .$..C"h....v...7
00a0 04 9A 89 C6 CE 9F 36 02 00 23 95 05 00 00 0C 80 ......6..#......
00b0 00 9A 03 08 12 31 9C 01 00 9F 02 06 00 00 00 00 .....1..........
00c0 09 00 5F 2A 02 08 40 82 02 78 00 5A 08 55 79 72 .._*..@..x.Z.Uyr
00d0 41 12 20 08 57 9F 1A 02 04 22 9F 03 06 00 00 00 A. .W...."......
00e0 00 00 00 9F 33 03 50 00 B0 9F 34 03 42 00 00 5F ....3.P...4.B.._
00f0 34 01 01 30 31 30 44 36 30 38 31 30 30 33 39 36 4..010D608100396

the de55 begin in the line 0070 after the the currency code 0840.
the value of de55 is :79
9F260895F40175549DF21E9F2701809F10120111A08003240400432268B6AE17F176D0149F37049A89C6CE9F36020023950500000C80009A030812319C01009F02060000000009005F2A020840820278005A0855797241122008579F1A0204229F03060000000000009F33035000B09F34034200005F340101
where 79 is the lenght.

thanks in advance for help and happy new year to all of jPOS-Users.

Regards,

Walid.

--
View this message in context: http://www.nabble.com/Parsing-Data-Element-55-for-Chip-Card-tp21231043p21231043.html
Sent from the jPOS - Users mailing list archive at Nabble.com.

[David Bergert]

Greetings:


What Type of Packager are you using ? Here is a short dump with
iso87binary.xml ...

Some basic questions:

It looks like field 49 is screwed up ? (This maybe cascading problems down
the rest of the message)

<unpack fld="49" packager="org.jpos.iso.IF_CHAR">
<value> @y</value>
Is that the expected values ? perhaps the length and type are not proper ?

Is that a test card number and track in de 35 ? It doesn't look like one.
Why type of message is this ?
What type of Terminal ?
What type of Terminal application ?
Do you have the specification of the message format ?
What do you expect in Field 55 and 61 ?

Specs are your friend ;)

See below:


<log realm="test" at="Wed Dec 31 07:27:17 CST 2008.621">
<unpack>

04003220448120E0820800000000000000090012311156120000005999005200100000402974
345579724112200857D1011201817400863F3030303031303220303030343232303030303031
3030324D45524348414E5420544553542053484C554D42455247454143485241464945482020
20204C424E0840799F260895F40175549DF21E9F2701809F10120111A08003240400432268B6
AE17F176D0149F37049A89C6CE9F36020023950500000C80009A030812319C01009F02060000
000009005F2A020840820278005A0855797241122008579F1A0204229F03060000000000009F
33035000B09F34034200005F34010130313044363038313030333936
<bitmap>{3, 4, 7, 11, 18, 22, 25, 32, 35, 41, 42, 43, 49, 55,
61}</bitmap>
<unpack fld="3" packager="org.jpos.iso.IFB_NUMERIC">
<value>000000</value>
</unpack>
<unpack fld="4" packager="org.jpos.iso.IFB_NUMERIC">
<value>000000000900</value>
</unpack>
<unpack fld="7" packager="org.jpos.iso.IFB_NUMERIC">
<value>1231115612</value>
</unpack>
<unpack fld="11" packager="org.jpos.iso.IFB_NUMERIC">
<value>000000</value>
</unpack>
<unpack fld="18" packager="org.jpos.iso.IFB_NUMERIC">
<value>5999</value>
</unpack>
<unpack fld="22" packager="org.jpos.iso.IFB_NUMERIC">
<value>052</value>
</unpack>
<unpack fld="25" packager="org.jpos.iso.IFB_NUMERIC">
<value>00</value>
</unpack>
<unpack fld="32" packager="org.jpos.iso.IFB_LLNUM">
<value>0000402974</value>
</unpack>
<unpack fld="35" packager="org.jpos.iso.IFB_LLNUM">
<value>5579724112200857=1011201817400863F</value>
</unpack>
<unpack fld="41" packager="org.jpos.iso.IF_CHAR">
<value>0000102 </value>
</unpack>
<unpack fld="42" packager="org.jpos.iso.IF_CHAR">
<value>000422000001002</value>
</unpack>
<unpack fld="43" packager="org.jpos.iso.IF_CHAR">
<value>MERCHANT TEST SHLUMBERGEACHRAFIEH LBN</value>
</unpack>
<unpack fld="49" packager="org.jpos.iso.IF_CHAR">
<value> @y</value>
</unpack>
<iso-exception>
org.jpos.iso.IFB_LLLCHAR: Problem unpacking field 55
<nested-exception>
java.lang.ArrayIndexOutOfBoundsException: 256
at
org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:55)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:173)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:233)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:342)
at jposmessageparsertest.Main.main(Main.java:63)
</nested-exception>
org.jpos.iso.ISOException: org.jpos.iso.IFB_LLLCHAR: Problem unpacking
field 55 (java.lang.ArrayIndexOutOfBoundsException: 256)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:178)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:233)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:342)
at jposmessageparsertest.Main.main(Main.java:63)
Nested:java.lang.ArrayIndexOutOfBoundsException: 256
at
org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:55)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:173)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:233)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:342)
at jposmessageparsertest.Main.main(Main.java:63)
</iso-exception>
<iso-exception>
org.jpos.iso.IFB_LLLCHAR: Problem unpacking field 55
<nested-exception>
java.lang.ArrayIndexOutOfBoundsException: 256
at
org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:55)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:173)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:233)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:342)
at jposmessageparsertest.Main.main(Main.java:63)
</nested-exception>
org.jpos.iso.ISOException: org.jpos.iso.IFB_LLLCHAR: Problem unpacking
field 55 (java.lang.ArrayIndexOutOfBoundsException: 256)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:178)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:233)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:342)
at jposmessageparsertest.Main.main(Main.java:63)
Nested:java.lang.ArrayIndexOutOfBoundsException: 256
at
org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:55)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:173)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:233)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:342)
at jposmessageparsertest.Main.main(Main.java:63)
</iso-exception>
</unpack>
</log>



David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com

[Andy Orrock]

You say there's "there are some variable length tag inside it". Like Dave
asks: what does the spec say? You've not provided enough guidance.

First things first though: that's a Hex length (79 --> 121, which is what
you've got there...you sound pretty confident about that, so let's go that
direction for now). That means you've to deal with the 'H' aspect of that.

Your field should, I think, be defined as IFB_LLHBINARY which will isolate
and pluck the data properly; then you can throw the contents into an TLV or
LTV parser (whichever your spec says you do).

That's how we do it in our implementations.

Andy Orrock

-----Original Message-----
From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
Behalf Of wshehab
Sent: Wednesday, December 31, 2008 6:49 AM
To: jpos-...@googlegroups.com
Subject: Parsing Data Element 55 for Chip Card

[David Bergert]

I changed packager field types for the values of 49,55,61 - to get this (see
below)

You can use the TLV or LTV classes or write/use a subpacker to deal with 55


<log realm="test" at="Wed Dec 31 08:40:30 CST 2008.45">

<unpack fld="49" packager="org.jpos.iso.IFB_NUMERIC">
<value>0840</value>
</unpack>
<unpack fld="55" packager="org.jpos.iso.IFB_LLHBINARY">
<value
type='binary'>9F260895F40175549DF21E9F2701809F10120111A08003240400432268B6AE
17F176D0149F37049A89C6CE9F36020023950500000C80009A030812319C01009F0206000000
0009005F2A020840820278005A0855797241122008579F1A0204229F03060000000000009F33
035000B09F34034200005F340101</value>
</unpack>
<unpack fld="61" packager="org.jpos.iso.IF_CHAR">
<value>010D608100396</value>
</unpack>

</unpack>
</log>



David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com

[Mark Salter]

wshehab wrote:
>
> i am trying now to unpack the the message that i received from POS terminal
> with my jpos server.

What will you be doing with this chip data?

Are you responsible for validating it, or are you just passing it
through to an Issuer?

> the message unpacked till de55. how can i create a special packager for de55
> because there are some variable length tag inside it.

Now your fun begins...

Treat the field as Andy suggest and take its byte[] content and pass it
through the org.jpos.tlv.TLVList.unpack(byte[]) method to unpack the
content into it's component parts:-

9F26 (Application Cryptogram).
0000 95 F4 01 75 54 9D F2 1E ...uT...

9F27
0000 80 .

9F10 (Issuer Application Data).
0000 01 11 A0 80 03 24 04 00 43 22 68 B6 AE 17 F1 76 .....$..C"h....v
0010 D0 14 ..

9F37 (Unpredictable Number).
0000 9A 89 C6 CE ....

9F36 (Application Transaction Counter).
0000 00 23 .#

95 (Terminal Verification Results).
0000 00 00 0C 80 00 .....

9A (Transaction Data).
0000 08 12 31 ..1

9C (Transaction Type).
0000 00 .

9F02 (Amount, Authorized).
0000 00 00 00 00 09 00 ......

5F2A (Transaction Currency Code).
0000 08 40 .@

82 (Application Interchange Profile).
0000 78 00 x.

5A (PAN).
0000 55 79 XX XX XX XX XX 57 UyxxxxxW

(N.B. Manually obscured as this may well not be a test card!!!)

9F1A (Terminal Country Code).
0000 04 22 ."

9F03 (Amount, Other).
0000 00 00 00 00 00 00 ......

9F33 (Terminal Capability Profile).
0000 50 00 B0 P..

9F34
0000 42 00 00 B..

5F34 (PAN Sequence Number).
0000 01 .

I have setup a *temporary* web service to parse your next attempt (or at
least until I take the server down:-

http://berilia.homedns.org:8081/9F260895F40175549DF21E9F2701809F10120111A08003240400432268B6AE17F176D0149F37049A89C6CE9F36020023950500000C80009A030812319C01009F02060000000009005F2A020840820278005A0855791111111111579F1A0204229F03060000000000009F33035000B09F34034200005F340101

which is the same as :-

http://tinyurl.com/jposdetag

You can play around with the data following the 3rd / for a while.

This 'webserver' code is posted in the file section of

The only caveat is that I double parse each field (to support TLV where
V can also holds TLVs), so occasionally you will see odd/useful
'fallout' 8).
I also obscured the PAN again just in case...!

--
Mark

[David Bergert]

While not a web service running Jetty/5.1.4 on Windows XP with java JRE
1.6.0_03 :)

The following code should help you get similar results:

TLVList tlv = new TLVList();
tlv.unpack((byte[])m.getValue(55));

byte[] iad = null;
int tag;
Enumeration enume = tlv.elements();
while(enume.hasMoreElements()){
TLVMsg tlvq = (TLVMsg)enume.nextElement();
iad = tlvq.getValue();
tag = tlvq.getTag();
System.out.println(Integer.toHexString(tag) + " : "
+ISOUtil.hexString(iad));


9f26 : 95F40175549DF21E
9f27 : 80
9f10 : 0111A08003240400432268B6AE17F176D014
9f37 : 9A89C6CE
9f36 : 0023
95 : 00000C8000
9a : 081231
9c : 00
9f02 : 000000000900
5f2a : 0840
82 : 7800
5a : 5579724112200857
9f1a : 0422
9f03 : 000000000000
9f33 : 5000B0
9f34 : 420000
5f34 : 01

Also see:

http://www.jpos.org/wiki/TLV
http://www.jpos.org/doc/javadoc/org/jpos/tlv/TLVList.html
http://www.jpos.org/doc/javadoc/org/jpos/tlv/TLVMsg.html

That was fun, we don't have alot of EMV stuff here in the States :)



Mark: you started a sentance below:

"This 'webserver' code is posted in the file section of"

I believe that you were planning to share the link of "your" source code ?

Regards,

David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com


> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On

[Mark Salter]

David Bergert wrote:
> While not a web service running Jetty/5.1.4 on Windows XP with java JRE
> 1.6.0_03 :)

Indeed, but just as functional 8).

> That was fun, we don't have alot of EMV stuff here in the States :)
>

We sometimes have too much over 'here'.

>
>
> Mark: you started a sentance below:
> "This 'webserver' code is posted in the file section of"
>
> I believe that you were planning to share the link of "your" source code ?

I did previously post this code to one of the File sections; went
looking but didn't find it and then hit send before deleting the
incomplete sentence 8(.

I have done so again in jpos-users:-

DetagWebService.java @

http://groups.google.co.uk/group/jpos-users/files?hl=en

Nothing special, but I do have it running locally for detagging
occasionally.

--
Mark

[wshehab]

Hi,

first, i would like to thanks all of you for your help,
Now i can accept the incoming message from pos terminal and parse it
correctly with Jpos.
you can see the log below:

<log realm="localhost.channel.packager" at="Fri Jan 02 15:28:09 GMT+02:00
2009.426">
<unpack>

02003220448120E0820800000000000000990001021527430000005999005200100000402974365889820000003885D101120600000473102F30303030303130323030303432323030303030313030324D45524348414E5420544553542053484C554D4245524745414348524146494548202020204C424E0840799F260807440CE7ADB8D0F29F2701809F10120111A000032404000000E1E8F4B443F1F5949F370480B60C009F3602000A950508000480009A030901029C01009F02060000000099005F2A020840820278005A0858898200000038859F1A0204229F03060000000000009F33035000B09F34030200005F34010130313044363038313030333936

<bitmap>{3, 4, 7, 11, 18, 22, 25, 32, 35, 41, 42, 43, 49, 55,
61}</bitmap>
<unpack fld="3" packager="org.jpos.iso.IFB_NUMERIC">
<value>000000</value>
</unpack>
<unpack fld="4" packager="org.jpos.iso.IFB_NUMERIC">

<value>000000009900</value>

</unpack>
<unpack fld="7" packager="org.jpos.iso.IFB_NUMERIC">

<value>0102152743</value>

</unpack>
<unpack fld="11" packager="org.jpos.iso.IFB_NUMERIC">
<value>000000</value>
</unpack>
<unpack fld="18" packager="org.jpos.iso.IFB_NUMERIC">
<value>5999</value>
</unpack>
<unpack fld="22" packager="org.jpos.iso.IFB_NUMERIC">
<value>052</value>
</unpack>
<unpack fld="25" packager="org.jpos.iso.IFB_NUMERIC">
<value>00</value>
</unpack>
<unpack fld="32" packager="org.jpos.iso.IFB_LLNUM">
<value>0000402974</value>
</unpack>
<unpack fld="35" packager="org.jpos.iso.IFB_LLNUM">

<value>5889820000003885=101120600000473102F</value>

</unpack>
<unpack fld="41" packager="org.jpos.iso.IF_CHAR">

<value>00000102</value>

</unpack>
<unpack fld="42" packager="org.jpos.iso.IF_CHAR">
<value>000422000001002</value>
</unpack>
<unpack fld="43" packager="org.jpos.iso.IF_CHAR">
<value>MERCHANT TEST SHLUMBERGEACHRAFIEH LBN</value>
</unpack>
<unpack fld="49" packager="org.jpos.iso.IFB_NUMERIC">

<value>840</value>

</unpack>
<unpack fld="55" packager="org.jpos.iso.IFB_LLHBINARY">
<value

type='binary'>9F260807440CE7ADB8D0F29F2701809F10120111A000032404000000E1E8F4B443F1F5949F370480B60C009F3602000A950508000480009A030901029C01009F02060000000099005F2A020840820278005A0858898200000038859F1A0204229F03060000000000009F33035000B09F34030200005F340101</value>
</unpack>
<unpack fld="61" packager="org.jpos.iso.IFA_LLLCHAR">
<value>D608100396</value>
</unpack>
</unpack>
</log>
ISOMSG OUT<-- 0200 000000 00000102
9f26 : 07440CE7ADB8D0F2
9f27 : 80
9f10 : 0111A000032404000000E1E8F4B443F1F594
9f37 : 80B60C00
9f36 : 000A
95 : 0800048000
9a : 090102
9c : 00
9f02 : 000000009900
5f2a : 0840
82 : 7800
5a : 5889820000003885

9f1a : 0422
9f03 : 000000000000
9f33 : 5000B0

9f34 : 020000
5f34 : 01

In the jpos server, i want to do some sort of modification related to the
tags in order to send back to the termianl. my question is how we can do
these verification and on which tags and which tags we should send back to
the terminal.
thanks in advance for your help.

--
View this message in context: http://www.nabble.com/Parsing-Data-Element-55-for-Chip-Card-tp21231043p21252160.html

[Mark Salter]

wshehab wrote:
>
> first, i would like to thanks all of you for your help,
> Now i can accept the incoming message from pos terminal and parse it
> correctly with Jpos.
> you can see the log below:

I have obscured your card again, please either confirm this is a test
card, or better still please stop posting your clear logs?

>
> <log realm="localhost.channel.packager" at="Fri Jan 02 15:28:09 GMT+02:00
> 2009.426">
> <unpack>
>

> 02003220448120E0820800000000000000990001021527430000005999005200100000402974365889XXXXXXXXXX85D101120600000473102F30303030303130323030303432323030303030313030324D45524348414E5420544553542053484C554D4245524745414348524146494548202020204C424E0840799F260807440CE7ADB8D0F29F2701809F10120111A000032404000000E1E8F4B443F1F5949F370480B60C009F3602000A950508000480009A030901029C01009F02060000000099005F2A020840820278005A0858898200000038859F1A0204229F03060000000000009F33035000B09F34030200005F34010130313044363038313030333936

> <value>5889XXXXXXXXXX85=101120600000473102F</value>

> </unpack>
> <unpack fld="41" packager="org.jpos.iso.IF_CHAR">
> <value>00000102</value>
> </unpack>
> <unpack fld="42" packager="org.jpos.iso.IF_CHAR">
> <value>000422000001002</value>
> </unpack>
> <unpack fld="43" packager="org.jpos.iso.IF_CHAR">
> <value>MERCHANT TEST SHLUMBERGEACHRAFIEH LBN</value>
> </unpack>
> <unpack fld="49" packager="org.jpos.iso.IFB_NUMERIC">
> <value>840</value>
> </unpack>
> <unpack fld="55" packager="org.jpos.iso.IFB_LLHBINARY">
> <value

> type='binary'>9F260807440CE7ADB8D0F29F2701809F10120111A000032404000000E1E8F4B443F1F5949F370480B60C009F3602000A950508000480009A030901029C01009F02060000000099005F2A020840820278005A085889XXXXXXXXXX859F1A0204229F03060000000000009F33035000B09F34030200005F340101</value>

> </unpack>
> <unpack fld="61" packager="org.jpos.iso.IFA_LLLCHAR">
> <value>D608100396</value>
> </unpack>
> </unpack>
> </log>
> ISOMSG OUT<-- 0200 000000 00000102
> 9f26 : 07440CE7ADB8D0F2
> 9f27 : 80
> 9f10 : 0111A000032404000000E1E8F4B443F1F594
> 9f37 : 80B60C00
> 9f36 : 000A
> 95 : 0800048000
> 9a : 090102
> 9c : 00
> 9f02 : 000000009900
> 5f2a : 0840
> 82 : 7800

> 5a : 5889XXXXXXXXXX85

> 9f1a : 0422
> 9f03 : 000000000000
> 9f33 : 5000B0
> 9f34 : 020000
> 5f34 : 01
>
>
> In the jpos server, i want to do some sort of modification related to the
> tags in order to send back to the termianl.

As I mentioned previously...
...now the fun starts.

> my question is how we can do
> these verification and on which tags and which tags we should send back to
> the terminal.

In basic terms, the value you need to send back to the card/terminal is
an ARPC. To generate this value, you need an HSM and a key management
infrastructure.

You validate the ARQC in the HSM which as part of it's response may
return an ARPC for an authorised response. Should the transaction fail
then a second call to your HSM will be needed to regenerate the ARPC for
the decline.

From your other posts, you seem to have a Thales HSM, are you already
talking to it and so can perform ARQC checking (and thus ARPC
generation)? You simply need to build the HSM request message from the
components of Field 55 and use values from the HSM response to populate
your response (ARPC, and perhaps scripts) back to the terminal.
Are you the Issuer in this exchange?

--
Mark

[wshehab]

Hi,
Mark Do not be worry about the card, sure it is a test card.
Now could you please give me more info and details about how we can do these
verification.

Thanks in advance for your help.

Walid.

--
View this message in context: http://www.nabble.com/Parsing-Data-Element-55-for-Chip-Card-tp21231043p21262769.html

[Zablon Ochomo]

I think the validations Mark meant are HSM verifications. In that case you will have to make some encryption commands to the HSM based on the fields you have got in DE 55 and compose a response.

By the way: I am doing the same project with POS (emv) like you. I have passed all fields well and next week I will start on DE 55! I have benefited already from this thread ;)

--
Zablon Ochomo

[Mark Salter]

wshehab wrote:
>
> Hi,
> Mark Do not be worry about the card, sure it is a test card.

Thank you for confirming this. I will suggest that it is never really a
good idea to publish any number in full and thus I would also advise you
against doing so.

> Now could you please give me more info and details about how we can do these
> verification.

I have given you a start, I think more than enough to be getting on with.

Perhaps this be more of a two-way discussion...?

I have asked a number of questions in the threads you have raised, but
apart for the confirmation above you have chosen not to answer my questions.

So:-

Are you an Issuer?
Did you emboss your cards yourself or do you use a bureau - do you have
the MDK's (encrypted or clear)?
How are you handling and controlling your key management?
You have a Thales HSM; did it come with a *manual*?
Have you determined the transactions you are going to be sending to your
HSM yet?

The data to extract from DE55 depends to a greater degree on what data
is needed as input to the HSM message, so some of the field data will be
concatenated to form the data into the HSM transaction, whilst other
fields will not be used.

I suggest you start by reading the HSM documentation, then when you have
a good idea of what you need to do, perhaps then we can provide specific
answers to specific questions.

I think you are looking for answers for questions from a height of 10000
feet. You need to bring yourself closer to the details so that you can
ask better questions.

Only IMHO of course.

8)

--
Mark

[wshehab]

Sorry Mark because i forgat to response to your questions in the previews
mail.

yes, we are the issuer and the aquirer for that card.
For the MDK's, we have the value in clear.
also we have a thales HSM and we use the P3 to genertate the EMV tags values
loaded to the card.

Thanks,

Walid.

--
View this message in context: http://www.nabble.com/Parsing-Data-Element-55-for-Chip-Card-tp21231043p21287335.html

[Mark Salter]

wshehab wrote:
>
> Sorry Mark because i forgat to response to your questions in the previews
> mail.

Thank you for coming back...

>
> yes, we are the issuer and the aquirer for that card.
> For the MDK's, we have the value in clear.
> also we have a thales HSM and we use the P3 to genertate the EMV tags values
> loaded to the card.

What transaction do you have for verifying the ARQC and producing an ARPC?
Do you have any custom Thales firmware at all?

--
Mark

[walid shehab]

Mark,

 

i want to verify the ARQC and generate the ARPC but without using the HSM.

[Mark Salter]

walid shehab wrote:
> Mark,
>
> i want to verify the ARQC and generate the ARPC but without using the HSM.

Why?

This could be done in software, but that would not be PCI compliant at all.

If you have an HSM, why try to avoid using it?

--
Mark

[walid shehab]

currently,

 we do not verify the ARQC in the production because MC drop the EMV part and send the transaction to us(the issuer) as magnetic. so in my case we are in the test invernement and we do not need to use the HSM. we should verify it in my progrm.

 

Walid.

[Mark Salter]

walid shehab wrote:
> currently,
> we do not verify the ARQC in the production because MC drop the EMV part
> and send the transaction to us(the issuer) as magnetic. so in my case we are
> in the test invernement and we do not need to use the HSM. we should verify
> it in my progrm.

Do MC currently generate the ARPC for you?

If not, then what are you trying to test?

To replicate your current processing, shouldn't you be stripping the
chip data off, so that your Issuer systems sees the transaction as it
would from MC?

Are you attempting to simulate MasterCard? Don't you have their
simulator? I can understand wanting to not use it all the time...

--
Mark

[walid shehab]

our connex switch now does not support EMV transaction. but in the test envirnement we are tying to build our new switch based on JPOS, so from the beginning we need to generate the ARPC with JPOS if that applicable.

 

Walid.

[walid shehab]

no MC dose not generate the ARPC from us. MC only drop the EMV part from the transaction and send it to our switch as magnetic for validation , once the transaction approved by our switch , the switch send the transaction back to MC and then MC add the EMV part to the transaction and send it back to the acquirer.

 

Walid.

[Mark Salter]

walid shehab wrote:
> our connex switch now does not support EMV transaction. but in the test
> envirnement we are tying to build our new switch based on JPOS, so from the
> beginning we need to generate the ARPC with JPOS if that applicable.

I think you have the wrong idea, sorry.

ARQC validation and ARPC generation *have* to be done in an HSM for a
production environment.

You may well build the switch in jPOS, but this will involve building a
message to send to your HSM and process the response.

You cannot conduct production grade processing in software alone, as I'm
sure your PCI team will confirm.

--
Mark

[Mark Salter]

walid shehab wrote:
> no MC dose not generate the ARPC from us. MC only drop the EMV part from the
> transaction and send it to our switch as magnetic for validation , once the
> transaction approved by our switch , the switch send the transaction back to
> MC and then MC add the EMV part to the transaction and send it back to the
> acquirer.

The EMV part on a response is the ARPC, the card won't be expecting much
else? As an acquirer, do you see an ARPC back on responses for your
cards? Who creates the ARPC if you are not?

--
Mark

[walid shehab]

we are only EMV issuer but not acquirer (till now).

for that reason  i have no much knowledge about how to generate the ARPC.

 

Walid.

[Mark Salter]

walid shehab wrote:
> we are only EMV issuer but not acquirer (till now).
> for that reason i have no much knowledge about how to generate the ARPC.

But the ARPC *is* Issuer generated, only the Issuer has the MDK of the
cards, so only the Issuer can build the ARPC (after validating the ARQC).

If you are to be an EMV Issuer that responds with a chip grade
transactions, then you may need to update your HSM firmware/version to
include the transactions you will need.

If you were replacing an Issuer component, then you may need the ARPC
code in this testing arrangement.

--
Mark

[walid shehab]

by the way,

if i want to connect jpos to MC credit simulator and use a MChip card, the simulator should validate and create the ARQC and ARPC.

(if i used a chip card from the TIP senario that i have).

how i can build the MC interface between jpos and MC simulator since there is no MC packager in jpos.

 

Walid.

[Mark Salter]

walid shehab wrote:
> by the way,
> if i want to connect jpos to MC credit simulator and use a MChip card, the
> simulator should validate and create the ARQC and ARPC.
> (if i used a chip card from the TIP senario that i have).
> how i can build the MC interface between jpos and MC simulator since there
> is no MC packager in jpos.

There are a couple that are close, extending these to add the EMV fields
is straightforward, so you start by building your packager.

Is your connection to MC EBDIC or ASCII?

--
Mark

[David Bergert]

 

how i can build the MC interface between jpos and MC simulator since there is no MC packager in jpos.

 

 

I would start with EUROPAY.xml, but it is an exercise to map the spec to the packager file, - this is something that you will need to do.

 

Andy's discusses this process at his blog here:

http://andyorrock.typepad.com/paymentsystems/2006/09/implementing_th.html

 

MC MIP's Support both an ASCII and EBCDIC formats and can be configured to one or the other (you will need to know which format your MIP uses)

[Dinero Machete]

hi guys (hi walid)

i am entrepreneur from switzerland and we are up to open a new security company named keysolutions.

i was searching the net for new people with knowledge about ARCQ.

maybe somebody is intrested in a partnership of course we can negotiate everything.

for messages please write me first instance on my gmail account (dineromachete@). of course we can use other secure messaging.

best regards.

Keysolutions (not yet GmBh)
a. guzman