[jpos-users] BASE24 PIN SYNCHRONIZATION/PIN LENGTH ERROR

Naija Coder

unread,

May 8, 2010, 1:29:08 PM5/8/10

to jPOS Users

Hi,

I've a Logon manager class which takes care of key exchange at
predetermined intervals. It respond well to key exchange perfectly and
logs the key to persistent store.

Currently am testing transactions through .bsh file accessible from
the ISO meter. All my 1200 messages always return PIN Synchronization
Error (128) or PIN Length Error (127).

Am padding the PIN field with preceding zeroes because my modified
channel packager always throw up an error if the clear PIN length is
less than 16 bytes.

Can anyone suggest what am not doing right?

Arthur

--
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users

Alejandro Revilla

unread,

May 8, 2010, 1:50:59 PM5/8/10

to jpos-...@googlegroups.com

I would have a look at JCESecurityModule's calculatePINBlock, pinblk has to be calculated differently depending on the format in use. That's something that takes place before encrypting it with the active key.

Naija Coder

unread,

May 8, 2010, 5:07:06 PM5/8/10

to jPOS Users

Thanks Alejandro for your speedy reply.

On May 8, 6:50 pm, Alejandro Revilla <a...@jpos.org> wrote:
> I would have a look at JCESecurityModule's calculatePINBlock, pinblk has to
> be calculated differently depending on the format in use. That's something
> that takes place before encrypting it with the active key.

Hmmm, my project uses org.bouncycastle and has no reference to the
JCESecurityModule, Like I said in my earlier post, bouncycastle
bounces an error whenever the clear pin is less than 16 bytes. So am
being forced to make the clear pin 16 bytes by preceding the actual
clear pin with zeroes. This actually encrypts the pin but the Base24-
eps complains about the pin length or pin synchronization error in
it's 1210 response message.

I think am forcing a hair or two to turn white from too much thinking,
over to da geeks in da house.

>
> On Sat, May 8, 2010 at 2:29 PM, Naija Coder <sureandsteadf...@gmail.com>wrote:
>
>
>
> > Hi,
>
> > I've a Logon manager class which takes care of key exchange at
> > predetermined intervals. It respond well to key exchange perfectly and
> > logs the key to persistent store.
>
> > Currently am testing transactions through .bsh file accessible from
> > the ISO meter. All my 1200 messages always return PIN Synchronization
> > Error (128) or PIN Length Error (127).
>
> > Am padding the PIN field with preceding zeroes because my modified
> > channel packager always throw up an error if the clear PIN length is
> > less than 16 bytes.
>
> > Can anyone suggest what am not doing right?
>
> > Arthur
>
> > --
> > You received this message because you are subscribed to the "jPOS Users"
> > group.

> > Please seehttp://jpos.org/wiki/JPOS_Mailing_List_Readme_first

> > To post to this group, send email to jpos-...@googlegroups.com

> > To unsubscribe, send email to jpos-users+...@googlegroups.com<jpos-users%2Bunsu...@googlegroups.com>

> > For more options, visit this group at
> >http://groups.google.com/group/jpos-users
>
> --
> You received this message because you are subscribed to the "jPOS Users" group.

> Please seehttp://jpos.org/wiki/JPOS_Mailing_List_Readme_first

> To post to this group, send email to jpos-...@googlegroups.com
> To unsubscribe, send email to jpos-users+...@googlegroups.com

> For more options, visit this group athttp://groups.google.com/group/jpos-users

Mark Salter

unread,

May 9, 2010, 4:39:25 AM5/9/10

to jpos-...@googlegroups.com

On 08/05/2010 22:07, Naija Coder wrote:

> Hmmm, my project uses org.bouncycastle and has no reference to the
> JCESecurityModule,

Ypui use bouncy castle to do what?

> Like I said in my earlier post, bouncycastle bounces an error
> whenever the clear pin is less than 16 bytes.

A bouncycastle problem would be asked about on a bouncycastle mailing
list? Also, whereabouts did you say this, which 'earlier post'?

A clear PIN *block* should be 8 bytes - unless represented in hexadecimal?

Can you show an example of where you get a PIN block is not 8 (16)?

I think you need to take care of the binary/hex versions of your data.
A PIN block is binary (8 bytes) and your 'crypto library' will deal with
the data as such.
The resultant PIN block *might* travel as 16 bytes (character hex) in
your message, but that is likely secondary to the process.

> So am being forced to make the clear pin 16 bytes by preceding the
> actual clear pin with zeroes.

You need to build the correct format clear PIN block.

> This actually encrypts the pin but the

Data goes in and get encrypted, but not the right data it seems.

> Base24- eps complains about the pin length or pin synchronization
> error in it's 1210 response message.

What PIN length are you specifying in your clear PIN block?

If B24 is expecting to find a length, then PIN block format 1 seems likely.

>
> I think am forcing a hair or two to turn white from too much
> thinking, over to da geeks in da house.

You don't need a 'da geeks', you just need to determine how/what you
should actually be doing.

8)

Don't forget to source that HSM for your production work!

--
Mark

Naija Coder

unread,

May 10, 2010, 3:08:28 AM5/10/10

to jPOS Users

Hi Mark,

Thanks for your reply,

> Ypui use bouncy castle to do what?

Cryptography

> > Like I said in my earlier post, bouncycastle bounces an error
> > whenever the clear pin is less than 16 bytes.
>
> A bouncycastle problem would be asked about on a bouncycastle mailing
> list? Also, whereabouts did you say this, which 'earlier post'?

Earlier post refers to the first message I sent under this topic. And
maybe you are right about the Bouncy Castle mailing list, if I can't
find help here I sure would head over there.

> A clear PIN *block* should be 8 bytes - unless represented in hexadecimal?
>
> Can you show an example of where you get a PIN block is not 8 (16)?
>
> I think you need to take care of the binary/hex versions of your data.
> A PIN block is binary (8 bytes) and your 'crypto library' will deal with
> the data as such.
> The resultant PIN block *might* travel as 16 bytes (character hex) in
> your message, but that is likely secondary to the process.
>

Below is an extract from my .bsh file

m.set(0,"1200");
m.set(2, strPAN);
m.set(3, "312000");
m.set(4, "000000000000");
m.set (7, ISODate.getDateTime(new Date()));
m.set (11, ISOUtil.zeropad(Long.toString(stan % 1000000), 6));
m.set (12, ISODate.formatDate(new Date(), "yy") + m.getString(7));
m.set(14, "1204");
m.set(22, "110010112004");
m.set(24, "108");
m.set(26, "0000");
m.set(32, "XXXXXX");
m.set(35, strTrack);
m.set(37, ISOUtil.padleft(m.getString(11), 12, '0'));
m.set(41, ISOUtil.padleft("1234", 16, '0'));
m.set(42, ISOUtil.padleft("1234", 15, '0'));
m.set(49, "566");
m.set(52, "000000000000XXXX");

The XXXX in field 52 represents the PIN, if I fail to precede the PIN
with the preceding zeros (to ensure it is exactly 16 bytes) I receive
the following errors:
<exception name="null">
java.lang.NullPointerException
at org.bouncycastle.util.encoders.HexEncoder.decode(Unknown
Source)
at org.bouncycastle.util.encoders.Hex.decode(Unknown Source)
at org.jpos.filters.PostFilter.filter(PostFilter.java:28)
at
org.jpos.iso.BaseChannel.applyOutgoingFilters(BaseChannel.java:879)
at org.jpos.iso.BaseChannel.send(BaseChannel.java:522)
at org.jpos.q2.iso.ChannelAdaptor
$Sender.run(ChannelAdaptor.java:247)
at java.lang.Thread.run(Thread.java:619)
</exception>

javax.crypto.IllegalBlockSizeException: data not block size aligned
at
org.bouncycastle.jce.provider.JCEBlockCipher.engineDoFinal(Unknown
Source)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at
org.jpos.crypto.Encryptor.TripleDesCalculator(Encryptor.java:96)
at org.jpos.crypto.Encryptor.decrypt(Encryptor.java:49)
at org.jpos.crypto.Encryptor.decryptMsg(Encryptor.java:120)
at org.jpos.filters.PostFilter.getPinBlock(PostFilter.java:71)
at org.jpos.filters.PostFilter.filter(PostFilter.java:26)
at
org.jpos.iso.BaseChannel.applyOutgoingFilters(BaseChannel.java:879)
at org.jpos.iso.BaseChannel.send(BaseChannel.java:522)
at org.jpos.q2.iso.ChannelAdaptor
$Sender.run(ChannelAdaptor.java:247)
at java.lang.Thread.run(Thread.java:619)

I tried converting the 4bytes PIN to binary and sending the binary
representation to no avail, am still getting the 128 or 127 error in
field 39

<field id="0" value="1210"/>
<field id="2" value="XXXXXX_______XXXX"/>
<field id="3" value="312000"/>
<field id="4" value="000000000000"/>
<field id="7" value="0508165958"/>
<field id="11" value="000002"/>
<field id="12" value="100508060051"/>
<field id="13" value="1005"/>
<field id="14" value="____"/>
<field id="15" value="100508"/>
<field id="19" value="566"/>
<field id="22" value="110010112004"/>
<field id="23" value="000"/>
<field id="30" value="000000000000000000000000"/>
<field id="32" value="627805"/>
<field id="35" value="XXXXXX_______XXXX=___________________"/>
<field id="37" value="000000000002"/>
<field id="39" value="128"/>

> You need to build the correct format clear PIN block.

May I ask how? And will you promise to reply without using your nerve
racking 8) rolling eyes?

> > This actually encrypts the pin but the
>
> Data goes in and get encrypted, but not the right data it seems.

Yes

> You don't need a 'da geeks', you just need to determine how/what you
> should actually be doing.
>
> 8)

There goes the rolling eyes again

>
> Don't forget to source that HSM for your production work!

Hahaha! I sure would NOT if I've enough time to figure it out - with
your help of course.

chhil

unread,

May 10, 2010, 3:27:54 AM5/10/10

to jpos-users

You keep mentioning PIN in your email which lead me to believe you are
transporting a pin and not a pinblock which does not seem correct. The
pin would never get sent in the clear in any message, the pin is
always sent in a pin block that is encrypted.
I think you are probably missing the part that field 52 is the
pinblock and not the pin.

This pinblock is 8 bytes (binary) and probably needs to be converted
to hex to get a length of 16 to comply with your data format of field
52.

-chhil

Naija Coder

unread,

May 10, 2010, 4:11:21 AM5/10/10

to jPOS Users

Hi Chhil,

Am actually transporting an 8byte hex PINBlock, the palaver is that
the 4byte PIN will not be encrypted if less than 16bytes.

> > Please seehttp://jpos.org/wiki/JPOS_Mailing_List_Readme_first

> > To post to this group, send email to jpos-...@googlegroups.com
> > To unsubscribe, send email to jpos-users+...@googlegroups.com

> > For more options, visit this group athttp://groups.google.com/group/jpos-users

>
> --
> You received this message because you are subscribed to the "jPOS Users" group.

> Please seehttp://jpos.org/wiki/JPOS_Mailing_List_Readme_first

> To post to this group, send email to jpos-...@googlegroups.com
> To unsubscribe, send email to jpos-users+...@googlegroups.com

> For more options, visit this group athttp://groups.google.com/group/jpos-users

chhil

unread,

May 10, 2010, 5:06:16 AM5/10/10

to jpos-users

Hi,

If I run the following I get your exception (watch the cipher instance
using NOPADDING)
I have used SUN's JCE and I am pretty sure Bouncy Castle also behaves
the same way.

KeySpec ks = new DESKeySpec("0909090909090909".getBytes());
SecretKeyFactory kf =SecretKeyFactory.getInstance("DES");
SecretKey ky = kf.generateSecret(ks);
Cipher cipher = Cipher.getInstance("DES/ECB/NOPADDING");
cipher.init(Cipher.ENCRYPT_MODE, ky);

//encrypt
byte[] cipherText = cipher.doFinal("1234".getBytes());

Output :
Exception in thread "main" javax.crypto.IllegalBlockSizeException:
Input length not multiple of 8 bytes
at com.sun.crypto.provider.SunJCE_f.a(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at Crypto.main(Crypto.java:52)

Now When I use padding (by changing the ciphers getinstance) the bytes
are aligned using the padding format it works as DES needs aligned
input. No need to manually align the byte array to fit the block size
expected
Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");

-chhil

chhil

unread,

May 10, 2010, 5:05:55 AM5/10/10

to jpos-users

Hi,

If I run the following I get your exception (watch the cipher instance
using NOPADDING)
I have used SUN's JCE and I am pretty sure Bouncy Castle also behaves
the same way.

KeySpec ks = new DESKeySpec("0909090909090909".getBytes());
SecretKeyFactory kf =SecretKeyFactory.getInstance("DES");
SecretKey ky = kf.generateSecret(ks);
Cipher cipher = Cipher.getInstance("DES/ECB/NOPADDING");
cipher.init(Cipher.ENCRYPT_MODE, ky);

//encrypt
byte[] cipherText = cipher.doFinal("1234".getBytes());

Output :
Exception in thread "main" javax.crypto.IllegalBlockSizeException:
Input length not multiple of 8 bytes
at com.sun.crypto.provider.SunJCE_f.a(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at Crypto.main(Crypto.java:52)

Now When I use padding (by changing the ciphers getinstance) the bytes
are aligned using the padding format it works as DES needs aligned
input. No need to manually align the byte array to fit the block size

expected by DES

Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");

-chhil

Mark Salter

unread,

May 10, 2010, 5:59:17 AM5/10/10

to jpos-...@googlegroups.com

On 10/05/2010 08:08, Naija Coder wrote:

>> Ypui use bouncy castle to do what?
> Cryptography

Yes, but what specifically - I was hoping you would say you were doing a
DES3 encryption of the clear PIN block using a key to produce an
encrypted PIN block; perhaps then I could ask to see the code that is
doing so (and failing).
I think you are trying to produce an encrypted PIN block, but might be
confusing yourself about what data goes in and how it is transported to
your target Issuer?

>
>>> Like I said in my earlier post, bouncycastle bounces an error
>>> whenever the clear pin is less than 16 bytes.
>>
>> A bouncycastle problem would be asked about on a bouncycastle mailing
>> list? Also, whereabouts did you say this, which 'earlier post'?
>
> Earlier post refers to the first message I sent under this topic. And
> maybe you are right about the Bouncy Castle mailing list, if I can't
> find help here I sure would head over there.

I couldn't see any mention of a bouncycastle error in your posts, hence
my question - just trying to keep you on track 8).

>
> Below is an extract from my .bsh file
>
> m.set(0,"1200");

[snip]

> m.set(52, "000000000000XXXX");
>
> The XXXX in field 52 represents the PIN, if I fail to precede the PIN
> with the preceding zeros (to ensure it is exactly 16 bytes) I receive
> the following errors:

The data in this field would need to be an even number of hex digits, so
that your code in your outgoingFilter can handle it correctly...

... The code in PostFilter.java (around line 28) would be useful need to
see.

You are saying you are setting the PIN (XXXX) in the clear in this field...
... this PIN value should never be held *anywhere* in clear - even in
the ISOMsg you are constructing.

The PIN should be encrypted by your input device and never handled in
the clear - never.

What are you using to get the PIN from the cardholder - I mean hardware
or method?

> I tried converting the 4bytes PIN to binary and sending the binary
> representation to no avail, am still getting the 128 or 127 error in
> field 39

> <field id="39" value="128"/>
>

Base24 is seeing junk and so assumes there is a key problem or data
error. Here there is a data error I think.

>> You need to build the correct format clear PIN block.
> May I ask how? And will you promise to reply without using your nerve
> racking 8) rolling eyes?
>

The Base24 system will define how they want you to present the PIN block
and their spec will include the format type, but perhaps will not
include the details of how.

As you mentioned that Base24 didn't like the length, then I would
suspect that PIN Block format 1 (ISO-0) is a likely candidate. If they
don't describe this for you, then google and you will find - possibly on
this mailing list...

... here is an example too, just to save google some power cycles 8).

PAN 1234567890123456
Clear PIN 1234

PIN Component (ISO-0) 041234FFFFFFFFFF // 04=PIN length
PAN Component 0000456789012345
Clear PIN block 0412719876FEDCBA

ZPK 07070707070707070707070707070707

Encrypted PIN Block D9CEAB0D5C6A42DC

This result is the data that will travel across the network in your
field 52, the ZPK ensures the PIN is protected - as is needed.

NB, I remember the PIN component as Format 1, but my google named it as
"ISO-0", so take care and confirm with Base24 admins what format they
want to see from you.

> There goes the rolling eyes again

Indeed 8), but only because this subject has come up before and google
returns "About 7,080,000 results (0.16 seconds)" for "PIN block format".

You do need to think long and hard about your PIN handling - PCI will
take a keen interest in how and what you do for your customers.

--
Beware of sharp sticks - I am currently unable to see properly and can
only spend limited time using any screen.
Nothing permanent, thank goodness!
Mark

Naija Coder

unread,

May 10, 2010, 6:08:38 AM5/10/10

to jPOS Users

Wow Chhil your suggestion was really helpful in that I do not have to
manually pad the 4byte PIN value key anymore. Thanks a million.

However, field 39 response code is still 128. Find below a sample
value for field 52

<field id="52" value="3D7A12A785B2E3D8" type="binary"/>

chhil

unread,

May 10, 2010, 6:20:24 AM5/10/10

to jpos-users

Please make sure to follow Marks last response and make sure you are
ONLY getting the clear pin as its a test system.

Name creating the correct pinblock format and encrypting it wit the
right key and using the right algorithm and padding.

All of the of the above variables will cause the output to change
causing Base24 to decline the message.

-chhil

Heru Nurasid

unread,

May 10, 2010, 6:24:01 AM5/10/10

to jpos-...@googlegroups.com

Hi,

If you don't try in real world using ATM or EDC machine is very dificult to get right PINBLOK field 52. Good luck to try more.....

++ Heru ++

--- On Mon, 5/10/10, Naija Coder <sureands...@gmail.com> wrote:

> >> > To unsubscribe, send email to jpos-users+unsub...@googlegroups.com

> >> > For more options, visit this group athttp://groups.google.com/group/jpos-users
>
> >> --
> >> You received this message because you are subscribed to the "jPOS Users" group.
> >> Please seehttp://jpos.org/wiki/JPOS_Mailing_List_Readme_first
> >> To post to this group, send email to jpos-...@googlegroups.com

> >> To unsubscribe, send email to jpos-users+unsub...@googlegroups.com

> >> For more options, visit this group athttp://groups.google.com/group/jpos-users
>
> > --
> > You received this message because you are subscribed to the "jPOS Users" group.
> > Please seehttp://jpos.org/wiki/JPOS_Mailing_List_Readme_first
> > To post to this group, send email to jpos-...@googlegroups.com

> > To unsubscribe, send email to jpos-users+unsub...@googlegroups.com

> > For more options, visit this group athttp://groups.google.com/group/jpos-users
>
> --
> You received this message because you are subscribed to the "jPOS Users" group.
> Please seehttp://jpos.org/wiki/JPOS_Mailing_List_Readme_first
> To post to this group, send email to jpos-...@googlegroups.com

> To unsubscribe, send email to jpos-users+unsub...@googlegroups.com

> For more options, visit this group athttp://groups.google.com/group/jpos-users

--
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com

To unsubscribe, send email to jpos-users+unsub...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/jpos-users

chhil

unread,

May 10, 2010, 6:29:07 AM5/10/10

to jpos-users

All the formats are standard creating stuff by hand/code for test should not in any way be different ...thats just been my experience with atms in symmetric key mode. Though I have not had much success with remote key transfers using certificates and what not.

-chhil

Naija Coder

unread,

May 10, 2010, 6:43:05 AM5/10/10

to jPOS Users

Bravo Mark,

For the first time since I started reading your posts I must say I do
not mind the rolling eyes, they are kinda cute, are they brown or
black?

> Yes, but what specifically - I was hoping you would say you were doing a
> DES3 encryption of the clear PIN block using a key to produce an
> encrypted PIN block; perhaps then I could ask to see the code that is
> doing so (and failing).

DES/TripleDES

> I think you are trying to produce an encrypted PIN block, but might be
> confusing yourself about what data goes in and how it is transported to
> your target Issuer?

Am not failing, the Pinblock is actually created, see below

> >>> Like I said in my earlier post, bouncycastle bounces an error
> >>> whenever the clear pin is less than 16 bytes.
>
> >> A bouncycastle problem would be asked about on a bouncycastle mailing
> >> list? Also, whereabouts did you say this, which 'earlier post'?
>
> > Earlier post refers to the first message I sent under this topic. And
> > maybe you are right about the Bouncy Castle mailing list, if I can't
> > find help here I sure would head over there.
>
> I couldn't see any mention of a bouncycastle error in your posts, hence
> my question - just trying to keep you on track 8).

8) 8) 8) sometimes it is nice to roll our eyes over our message before
posting, this will save Mark from rolling his

>
>
> > Below is an extract from my .bsh file
>
> > m.set(0,"1200");
> [snip]
> > m.set(52, "000000000000XXXX");
>
> > The XXXX in field 52 represents the PIN, if I fail to precede the PIN
> > with the preceding zeros (to ensure it is exactly 16 bytes) I receive
> > the following errors:
>
> The data in this field would need to be an even number of hex digits, so
> that your code in your outgoingFilter can handle it correctly...

The value of field 52 is actually passed to Postfilter.java (which I
specified in my channel xml file as one of the outgoing filters)

> ... The code in PostFilter.java (around line 28) would be useful need to
> see.
>
> You are saying you are setting the PIN (XXXX) in the clear in this field...
> ... this PIN value should never be held *anywhere* in clear - even in
> the ISOMsg you are constructing.
>
> The PIN should be encrypted by your input device and never handled in
> the clear - never.

Roger (thanks for not rolling your eyes here Mark)

> What are you using to get the PIN from the cardholder - I mean hardware
> or method?

We are still building test messages, hence the use of test card, which
is supplied by the B24. We are yet to determine what PIN capture
method to use.

> > I tried converting the 4bytes PIN to binary and sending the binary
> > representation to no avail, am still getting the 128 or 127 error in
> > field 39
> > <field id="39" value="128"/>
>
> Base24 is seeing junk and so assumes there is a key problem or data
> error. Here there is a data error I think.

Hmmm, hope the 'type="binary'" below is not the cause of the junk?

> >> You need to build the correct format clear PIN block.

The solution generates the pin value from the clear PIN which is then
used to generate the pinblock as you clear demonstrated in your MOST
INSTRUCTIVE POST EVER (seems the light use of your trademark rolling
eyes made me to get the best from your post tnks)

Mark Salter

unread,

May 10, 2010, 8:15:22 AM5/10/10

to jpos-...@googlegroups.com

On 10/05/2010 11:43, Naija Coder wrote:
> For the first time since I started reading your posts I must say I do
> not mind the rolling eyes, they are kinda cute, are they brown or
> black?

Blue.

8)

>
>> Yes, but what specifically - I was hoping you would say you were doing a
>> DES3 encryption of the clear PIN block using a key to produce an
>> encrypted PIN block; perhaps then I could ask to see the code that is
>> doing so (and failing).
>
> DES/TripleDES
>
>> I think you are trying to produce an encrypted PIN block, but might be
>> confusing yourself about what data goes in and how it is transported to
>> your target Issuer?
> Am not failing, the Pinblock is actually created, see below
>
> <field id="52" value="3D7A12A785B2E3D8" type="binary"/>

8)

Just because you get a value to send, it doesn't mean it is the right
value constructed with the right data content format and keys.

The response from Base24, seems to indicate that something is wrong...

>> What are you using to get the PIN from the cardholder - I mean hardware
>> or method?
>
> We are still building test messages, hence the use of test card, which
> is supplied by the B24. We are yet to determine what PIN capture
> method to use.

Ok.

>
>>> I tried converting the 4bytes PIN to binary and sending the binary
>>> representation to no avail, am still getting the 128 or 127 error in
>>> field 39
>>> <field id="39" value="128"/>
>>
>> Base24 is seeing junk and so assumes there is a key problem or data
>> error. Here there is a data error I think.
>
> Hmmm, hope the 'type="binary'" below is not the cause of the junk?

No, it is likely to be the content of the PIN not being what Base24 is
setup to expect or bad keys. The recipient (Base24) will define how to
transmit the data - of course.

That's the hard bit about cryptography, getting the data right.

>
> <field id="52" value="3D7A12A785B2E3D8" type="binary"/>

Can you provide the test transport keys and PAN please? If you have the
clear PIN or indeed the PIN key, I can provide a sample of the result
you should be getting...

... I will need to know what PIN block format you want though 8).

>
>
>>>> You need to build the correct format clear PIN block.
> The solution generates the pin value from the clear PIN which is then
> used to generate the pinblock as you clear demonstrated in your MOST
> INSTRUCTIVE POST EVER (seems the light use of your trademark rolling
> eyes made me to get the best from your post tnks)
>

I have provided much better answers than this - my injury limits my
response length; certainly rolling my eyes can only be in my mind - it
hurts too much to do it for real.

Smart questions always get good answers.

As Eric and Rick would confirm and guide :-

http://catb.org/~esr/faqs/smart-questions.html

--
Mark

Naija Coder

unread,

May 11, 2010, 8:46:11 AM5/11/10

to jPOS Users

Hi Mark,

Thanks a million for the info. Luckily for us we are still testing the
switch and hence can change the keys I sent to you prior to going live/
production.

I forgot to mention in my earlier post that I've an incoming filter
which handles key exchange requests, (whether initiated manually or
automatically at intervals of 600000 by the logon manager class). Each
time a key change request is initiated, the new KEK is saved to
persistent (kwp-switch) storage after being extracted from field 96

Am posting extracted log info here in case it might help to show where
am FAILING BIG TIME (please observe that the value of kwp-switch keeps
changing each time a key exchange is initiated, it is this value that
is used to encrypt the pinblock, this is the value extracted from
field 96)

<log realm="packager-debug" at="Tue May 11 13:25:21 WAT 2010.82">
<pack>

3138303438323341303130303030303030303230303030303030303030303030303030383035313130313235323130303030303031303035313130313235323131303035313030353131383031303339313237313930333136323738303520202030202020202020202020202020202020202020202020303030
</pack>
</log>
<log realm="channel/xxx.xxx.xxx.xxx:xxxxx" at="Tue May 11 13:25:21 WAT
2010.157">
<send>
<PinValue>null</PinValue>
<isomsg direction="outgoing">

<field id="0" value="1804"/>
<field id="7" value="0511012521"/>
<field id="11" value="000000"/>
<field id="12" value="100511012521"/>

<field id="15" value="100511"/>
<field id="24" value="831"/>
<field id="39" value="800"/>
<field id="59" value="12719031627805 0 "/>
<field id="125" value=""/>
</isomsg>
</send>
</log>
<log realm="channel/xxx.xxx.xxx.xxx:xxxxx" at="Tue May 11 13:25:21 WAT
2010.516">
<receive>
<isomsg direction="incoming">

<field id="0" value="1804"/>
<field id="7" value="0511122429"/>
<field id="11" value="382713"/>
<field id="12" value="100511132429"/>
<field id="24" value="831"/>
</isomsg>
</receive>
</log>
<log realm="packager-debug" at="Tue May 11 13:25:22 WAT 2010.92">
<unpack>

313831343032333030313030303230303030323030353131313232343330303030303030313030353131303132353231383031383030303339313237313930333136323738303520202030202020202020202020202020202020202020202020
<bitmap>{7, 11, 12, 24, 39, 59}</bitmap>
<unpack fld="7" packager="org.jpos.iso.IFA_NUMERIC">
<value>0511122430</value>
</unpack>
<unpack fld="11" packager="org.jpos.iso.IFA_NUMERIC">
<value>000000</value>
</unpack>
<unpack fld="12" packager="org.jpos.iso.IFA_NUMERIC">
<value>100511012521</value>
</unpack>
<unpack fld="24" packager="org.jpos.iso.IFA_NUMERIC">
<value>801</value>
</unpack>
<unpack fld="39" packager="org.jpos.iso.IFA_NUMERIC">
<value>800</value>
</unpack>
<unpack fld="59" packager="org.jpos.iso.IFA_LLLCHAR">
<value>12719031627805 0 </value>
</unpack>
</unpack>
</log>
<log realm="channel/xxx.xxx.xxx.xxx:xxxxx" at="Tue May 11 13:25:22 WAT
2010.145">
<receive>
<isomsg direction="incoming">

<field id="0" value="1814"/>
<field id="7" value="0511122430"/>
<field id="11" value="000000"/>
<field id="12" value="100511012521"/>
<field id="24" value="801"/>
<field id="39" value="00"/>
<field id="59" value="12719031627805 0 "/>
</isomsg>
</receive>
</log>
<log realm="org.jpos.core.qbeans.LogonManager" at="Tue May 11 13:25:22
WAT 2010.171">
<info>
Logon successfull (Session ID Tue May 11 13:25:20 WAT 2010)
</info>
</log>
<log realm="org.jpos.core.qbeans.LogonManager" at="Tue May 11 13:25:22
WAT 2010.198">
<debug>
initiating echo sequence
</debug>
</log>
<log realm="packager-debug" at="Tue May 11 13:25:22 WAT 2010.233">
<pack>

3138303438323341303130303030303030303230303030303030303030303030303030383035313130313235323230303030303031303035313130313235323231303035313030353131383331303339313237313930333136323738303520202030202020202020202020202020202020202020202020303030
</pack>
</log>
<log realm="channel/xxx.xxx.xxx.xxx:xxxxx" at="Tue May 11 13:25:22 WAT
2010.269">
<send>
<PinValue>null</PinValue>
<isomsg direction="outgoing">

<field id="0" value="1804"/>
<field id="7" value="0511012522"/>
<field id="11" value="000000"/>
<field id="12" value="100511012522"/>

<field id="15" value="100511"/>
<field id="24" value="831"/>
<field id="59" value="12719031627805 0 "/>
<field id="125" value=""/>
</isomsg>
</send>
</log>
<log realm="packager-debug" at="Tue May 11 13:25:23 WAT 2010.138">
<unpack>

313831343032333030313030303230303030323030353131313232343331303030303030313030353131303132353232383331383030303339313237313930333136323738303520202030202020202020202020202020202020202020202020
<bitmap>{7, 11, 12, 24, 39, 59}</bitmap>
<unpack fld="7" packager="org.jpos.iso.IFA_NUMERIC">
<value>0511122431</value>
</unpack>
<unpack fld="11" packager="org.jpos.iso.IFA_NUMERIC">
<value>000000</value>
</unpack>
<unpack fld="12" packager="org.jpos.iso.IFA_NUMERIC">
<value>100511012522</value>
</unpack>
<unpack fld="24" packager="org.jpos.iso.IFA_NUMERIC">
<value>831</value>
</unpack>
<unpack fld="39" packager="org.jpos.iso.IFA_NUMERIC">
<value>800</value>
</unpack>
<unpack fld="59" packager="org.jpos.iso.IFA_LLLCHAR">
<value>12719031627805 0 </value>
</unpack>
</unpack>
</log>
<log realm="channel/xxx.xxx.xxx.xxx:xxxxx" at="Tue May 11 13:25:23 WAT
2010.169">
<receive>
<isomsg direction="incoming">

<field id="0" value="1814"/>
<field id="7" value="0511122431"/>
<field id="11" value="000000"/>
<field id="12" value="100511012522"/>
<field id="24" value="831"/>
<field id="39" value="00"/>
<field id="59" value="12719031627805 0 "/>
</isomsg>
</receive>
</log>
<log realm="org.jpos.core.qbeans.LogonManager" at="Tue May 11 13:25:23
WAT 2010.189">
<info>
Echo successful
</info>
</log>
<log realm="org.jpos.core.qbeans.LogonManager" at="Tue May 11 13:25:23
WAT 2010.204">
<debug>
initiating key exchange
</debug>
</log>
<log realm="packager-debug" at="Tue May 11 13:25:23 WAT 2010.345">
<pack>

3138303438323341303130303030303030303230303030303030303030303030303030383035313130313235323330303031323631303035313130313235323331303035313030353131383138303339313237313930333136323738303520202030202020202020202020202020202020202020202020303030
</pack>
</log>
<log realm="channel/xxx.xxx.xxx.xxx:xxxxx" at="Tue May 11 13:25:23 WAT
2010.382">
<send>
<PinValue>null</PinValue>
<isomsg direction="outgoing">

<field id="0" value="1804"/>
<field id="7" value="0511012523"/>
<field id="11" value="000126"/>
<field id="12" value="100511012523"/>

<field id="15" value="100511"/>
<field id="24" value="818"/>
<field id="59" value="12719031627805 0 "/>
<field id="125" value=""/>
</isomsg>
</send>
</log>
<log realm="packager-debug" at="Tue May 11 13:25:24 WAT 2010.289">
<unpack>

313831343032333030313030303230303030323030353131313232343332303030313236313030353131303132353233383138383030303339313237313930333136323738303520202030202020202020202020202020202020202020202020
<bitmap>{7, 11, 12, 24, 39, 59}</bitmap>
<unpack fld="7" packager="org.jpos.iso.IFA_NUMERIC">
<value>0511122432</value>
</unpack>
<unpack fld="11" packager="org.jpos.iso.IFA_NUMERIC">
<value>000126</value>
</unpack>
<unpack fld="12" packager="org.jpos.iso.IFA_NUMERIC">
<value>100511012523</value>
</unpack>
<unpack fld="24" packager="org.jpos.iso.IFA_NUMERIC">
<value>818</value>
</unpack>
<unpack fld="39" packager="org.jpos.iso.IFA_NUMERIC">
<value>800</value>
</unpack>
<unpack fld="59" packager="org.jpos.iso.IFA_LLLCHAR">
<value>12719031627805 0 </value>
</unpack>
</unpack>
</log>
<log realm="channel/xxx.xxx.xxx.xxx:xxxxx" at="Tue May 11 13:25:24 WAT
2010.318">
<receive>
<isomsg direction="incoming">

<field id="0" value="1814"/>
<field id="7" value="0511122432"/>
<field id="11" value="000126"/>
<field id="12" value="100511012523"/>
<field id="24" value="818"/>
<field id="39" value="00"/>
<field id="59" value="12719031627805 0 "/>
</isomsg>
</receive>
</log>
<log realm="org.jpos.core.qbeans.LogonManager" at="Tue May 11 13:25:24
WAT 2010.355">
<info>
Session Key null
</info>
</log>
<log realm="kwp-switch" at="Tue May 11 13:25:24 WAT 2010.376">
<set-key>
<alias>main</alias>
<secure-des-key length="16" type="DES">
<data></data>
<check-value>000000</check-value>
</secure-des-key>
</set-key>
</log>
<log realm="org.jpos.core.qbeans.LogonManager" at="Tue May 11 13:25:24
WAT 2010.386">
<info>
Key Exchange successfull (Session ID Tue May 11 13:25:20 WAT 2010)
</info>
</log>
<log realm="packager-debug" at="Tue May 11 13:25:25 WAT 2010.680">
<unpack>

3138303438323330303130303030303030303030303030303030303130303030303030303035313131323234333333383235363331303035313131333234333338303930363130313030323030303330303132303430333239383841414146413032333336323038463642353635343443383543313843463035303036383833303041
<bitmap>{1, 7, 11, 12, 24, 96}</bitmap>
<unpack fld="7" packager="org.jpos.iso.IFA_NUMERIC">
<value>0511122433</value>
</unpack>
<unpack fld="11" packager="org.jpos.iso.IFA_NUMERIC">
<value>382563</value>
</unpack>
<unpack fld="12" packager="org.jpos.iso.IFA_NUMERIC">
<value>100511132433</value>
</unpack>
<unpack fld="24" packager="org.jpos.iso.IFA_NUMERIC">
<value>809</value>
</unpack>
<unpack fld="96" packager="org.jpos.iso.IFA_LLLCHAR">

<value>010020003001204032988AAAFA02336208F6B56544C85C18CF0500688300A</
value>
</unpack>
</unpack>
</log>
<log realm="kwp-switch" at="Tue May 11 13:25:25 WAT 2010.701">
<set-key>
<alias>main</alias>
<secure-des-key length="16" type="DES">
<data>988AAAFA02336208F6B56544C85C18CF</data>
<check-value>88300A</check-value>
</secure-des-key>
</set-key>
</log>
<log realm="packager-debug" at="Tue May 11 13:25:25 WAT 2010.724">
<pack>

3138313438323341303130303032303030303230303030303030303030303030303030383035313130313235323533383235363331303035313130313235323531303035313030353131383039383030303339313237313930333136323738303520202030202020202020202020202020202020202020202020303030
</pack>
</log>
<log realm="channel/xxx.xxx.xxx.xxx:xxxxx" at="Tue May 11 13:25:25 WAT
2010.760">
<send>
<PinValue>null</PinValue>
<isomsg direction="outgoing">

<field id="0" value="1814"/>
<field id="7" value="0511012525"/>
<field id="11" value="382563"/>
<field id="12" value="100511012525"/>

<field id="0" value="1210"/>

chhil

unread,

May 11, 2010, 9:48:32 AM5/11/10

to jpos-users

Please determine if any variants have been applied or expected to be
applied on the keys during the exchange.
usually in the network zone I have seen the application of variants.
-chhil

hairi

unread,

May 12, 2010, 2:41:35 AM5/12/10

to jpos-...@googlegroups.com

Hi All,

If your using pinblock ISO format 1, you can use my hsm simulator to
generate the encrypted pinblock value.
its at www.m-sinergi.com/hairi

Best Regards,
Hairi

Naija Coder

unread,

May 12, 2010, 4:30:50 AM5/12/10

to jPOS Users

Hi Chhil,

Thanks for your reply, find below the code for the that handles
pinblock:

public class PostFilter extends BaseFilter
{
public ISOMsg filter(ISOChannel arg0, ISOMsg arg1, LogEvent evt)
throws ISOFilter.VetoException
{
try
{
String pValue = arg1.getString(52);
String cValue = arg1.getString(53);
evt.addMessage("PinValue", pValue);
if ((pValue != null) && (!pValue.trim().equalsIgnoreCase(""))) {
String pinBlock = getPinBlock(pValue);

arg1.set(52, Hex.decode(pinBlock));
if ((cValue != null) && (!cValue.trim().equalsIgnoreCase("")))
{
String c_pinBlock = getPinBlock(cValue);
String str = "01" + c_pinBlock;
while (str.length() < 96) {
str = str + "30";
}
arg1.set(53, ISOUtil.hex2byte(str));
}
} else {
arg1.unset(52);
}

String fld37 = arg1.getString(37);
if (fld37 != null) {
try
{
arg1.set(37, ISOUtil.zeropad(fld37, 12));
}
catch (Exception ex)
{
evt.addMessage("error_pos", ex.getMessage());
}

}

}
catch (ISOException e)
{
error(e);
}
return super.filter(arg0, arg1, evt);
}

private String getPinBlock(String pinValue) {
String pin_block = null;
try
{
KeyStorageFacility ksf = new KeyStorageFacility();
debug("Finished testing session key");
String encrypted_pin_zoneA = pinValue;
debug("Pin value", encrypted_pin_zoneA);

String enrypted_pin_zoneB =
Encryptor.decryptMsg(encrypted_pin_zoneA, ksf.getKSK());
debug("encrypted_zone_b: " + enrypted_pin_zoneB);

PinblockEncryptor gen = new PinblockEncryptor();
String session_key = ksf.getKEK(this.cfg.get("kek"));
debug("Session key: " + session_key);
String zmk = ksf.getZMK(this.cfg.get("zmk"));

pin_block = gen.getCustomEncryptedPinBlock(enrypted_pin_zoneB,
session_key, zmk, true);

if (pin_block.length() > 16)
pin_block = pin_block.substring(0, 16);
return pin_block;
} catch (Exception ex) {
error(ex);
ex.printStackTrace(System.out);
}
return pin_block;
}
}

Code fragments from other classes called from class above:

------------------------------------------------------------ Fragement
1
--------------------------------------------------------------------------------------
public String getCustomEncryptedPinBlock(String pin_padd, String
sessionKey, String zmk, boolean clearZMK)
throws Exception
{
String str2 = Encryptor.decryptMsg(sessionKey, zmk);
System.out.println("clear pin key " + str2);
return Encryptor.encryptMsg(pin_padd, str2);
}

------------------------------------------------------------ Fragment
2
--------------------------------------------------------------------------------------
public static synchronized String decryptMsg(String data, String
key) throws Exception
{
int size = data.length() / 2;

String key1 = "1";
String key2 = "2";
String decrypted = "";
String encrypted = "";
try {
if (key.length() == 32) {
key1 = key.substring(0, 16);
key2 = key.substring(16, 32);
}

if (key.length() == 16) {
decrypted = decrypt(DES, data, key, size);
} else if (key1.equalsIgnoreCase(key2)) {
decrypted = decrypt(DES, data, key1, size);
encrypted = encrypt(DES, decrypted, key2, size);
decrypted = decrypt(DES, encrypted, key2, size);
} else if (key.length() == 32) {
decrypted = decrypt(TripleDES, data, key, size);
}
} catch (Exception exc) {
throw exc;
}

return decrypted;

}

On May 11, 2:48 pm, chhil <chil...@gmail.com> wrote:
> Please determine if any variants have been applied or expected to be
> applied on the keys during the exchange.
> usually in the network zone I have seen the application of variants.
> -chhil
>

> ...
>
> read more »

chhil

unread,

May 14, 2010, 12:19:14 AM5/14/10

to jpos-users

My gut feeling is that your keys a 32 wide and key1 is not equal to key.
It falling into the-> decrypted = decrypt(TripleDES, data, key, size);

I believe for Triple Des using double length keys you may need to
append the first 16 of the double length key to the key.
If you are already doing that in the decrypt(...) then thats fine,
otherwise I could not spot an issue with your code fragments.

The key1.equalsIgnoreCase(key2) seems a little wasteful coz I think
HSM may not provide weak keys where key1 will be equal to key2, pplus
you can simply let the
decrypt(TripleDES, data, key, size) handle it rather than doing triple
des yourself.

-chhil

Reply all

Reply to author

Forward