ARQC Generation for Test purposes

13,621 views
Skip to first unread message

Billie

unread,
Jan 12, 2015, 3:19:51 AM1/12/15
to jpos-...@googlegroups.com
Hello!

Does anyone know the algorithm VISA and MasterCard uses to generate the ARQC? I know they have different algorithms, and I didn't find anything detailed enough the verify a generated ARQC. For example, http://www.emvlab.org/cryptogram/ provides an online form - but the result dosen't match. It may be that I had the wrong values for transaction data, but there is also no option for the algorithm. I've also tried the Thales Simulator, but the Implementation seems broken. The JCESecurityModule in jPOS doesn't implement the verifyARQCImpl-Method, but that's exactly what I'm looking for.

Best regards
Billie

Mark Salter

unread,
Jan 12, 2015, 7:15:48 AM1/12/15
to jpos-...@googlegroups.com
On Monday, January 12, 2015 at 8:19:51 AM UTC, Billie wrote:
Hello!
Hi

Does anyone know the algorithm VISA and MasterCard uses to generate the ARQC? I know they have different algorithms, and I didn't find anything detailed enough the verify a generated ARQC.
You really need to dig around the scheme documentation for your answer.
 
For example, http://www.emvlab.org/cryptogram/ provides an online form - but the result dosen't match. It may be that I had the wrong values for transaction data, but there is also no option for the algorithm. I've also tried the Thales Simulator, but the Implementation seems broken.

Your failure on the online test/check is as likely keys as input data.

If your check with both the emvlab and Thales sim don't match your transaction - are you certain of your data and your key?

I do have the means personally, but not anything I can give away - hence my suggestion of reading the current manuals .

:-(

Perhaps someone else can be more helpful,

The JCESecurityModule in jPOS doesn't implement the verifyARQCImpl-Method, but that's exactly what I'm looking for.
Of course that is the work people often can't share and everyone needs to do for themselves in reality.

--
Mark

Billie

unread,
Jan 13, 2015, 9:34:10 AM1/13/15
to jpos-...@googlegroups.com
The JCESecurityModule seems to have the code needed for generating/verifying a ARQC. There are the Methods for ICC Master Key Derivation (deriveICCMasterKey), Session Key Derivation (deriveSK_VISA, deriveCommonSK_SM) and finally Padding/MAC generation (paddingISO9797Method2, calculateMACISO9797Alg3).

The Thales sim generates the same ICC Master Key as jPOS, but I could not find where session key derivation takes place in the Thales sim sources. The emvlab.org provides no sources at all.

My major problem seems to build valid input data. Does anyone know the exact data elements (format, values, ...) used by MasterCard and or VISA for Application Cryptogram generation?

Mark Salter

unread,
Jan 13, 2015, 11:50:52 AM1/13/15
to jpos-...@googlegroups.com


On Tuesday, January 13, 2015 at 2:34:10 PM UTC, Billie wrote:
The Thales sim generates the same ICC Master Key as jPOS, but I could not find where session key derivation takes place in the Thales sim sources.
They are there to find I'm sure.
 
The emvlab.org provides no sources at all.
I guess they choose not to do so.
 

My major problem seems to build valid input data. Does anyone know the exact data elements (format, values, ...) used by MasterCard and or VISA for Application Cryptogram generation?
What data have you got, can you share all your test data and results you are getting, this might help us see what you are doing wrong?

The data into the ARQC is :-

Transaction Amount
Other Amount
Terminal Country Code
Terminal Verification Results
Transaction Currency Code
Transaction Date
Transaction Type
Unpredictable Number
Application Interchange Profile
Application Transaction Counter
Card Verification Results

suffixed with an added x'80' for MasterCard (the code you are using might take care of this), but is that what you mean by "exact data elements"?

I'm struggling to work out what position you are in - if you need guidance or code?

What HSMs are you using or planning to use outside of test?

--
Mark
 

Billie

unread,
Jan 14, 2015, 3:27:14 AM1/14/15
to jpos-...@googlegroups.com
I prefer code over specifications ;) This is my basic example, I have removed the Issuer Master Key:

    public static void main(String[] args) throws Exception {
       
byte[] amountAuhtorised = ISOUtil.hex2byte("000000001000");
       
byte[] amountOther = ISOUtil.hex2byte("000000000000");
       
byte[] terminalCountryCode = ISOUtil.hex2byte("0040");
       
byte[] terminalVerificationResults = ISOUtil.hex2byte("8000048000");
       
byte[] transactionCurrencyCode = ISOUtil.hex2byte("0978");
       
byte[] transactionDate = ISOUtil.hex2byte("100514");
       
byte[] transactionType = ISOUtil.hex2byte("01");
       
byte[] unpredictableNumber = ISOUtil.hex2byte("2E13374C");
       
byte[] applicationInterchangeProfile = ISOUtil.hex2byte("1800");
       
byte[] applicationTransactionCounter = ISOUtil.hex2byte("0014");
       
byte[] cvmResults = ISOUtil.hex2byte("020300");

       
JCESecurityModule module = new JCESecurityModule("secret.lmk", BouncyCastleProvider.class.getCanonicalName());
       
byte[] iMk = ISOUtil.hex2byte("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX");
       
byte[] panpsn = JCESecurityModule.formatPANPSN("1234567890123456", null, MKDMethod.OPTION_A);

       
System.out.println("PAN: " + ISOUtil.byte2hex(panpsn));

       
Key key = new SecretKeySpec(iMk, "DESede");
       
Key iccMk = module.deriveICCMasterKey(key, panpsn);
       
System.out.println("iccMk: " + ISOUtil.byte2hex(iccMk.getEncoded()));

       
Key sKey = module.deriveCommonSK_SM(iccMk, applicationTransactionCounter);
       
System.out.println("sKey: " + ISOUtil.byte2hex(sKey.getEncoded()));

       
ByteArrayOutputStream outStream = new ByteArrayOutputStream();
        outStream
.write(amountAuhtorised);
        outStream
.write(amountOther);
        outStream
.write(terminalCountryCode);
        outStream
.write(terminalVerificationResults);
        outStream
.write(transactionCurrencyCode);
        outStream
.write(transactionDate);
        outStream
.write(transactionType);
        outStream
.write(unpredictableNumber);
        outStream
.write(applicationInterchangeProfile);
        outStream
.write(applicationTransactionCounter);
        outStream
.write(cvmResults);
        outStream
.write(ISOUtil.hex2byte("80"));

       
byte[] data = module.paddingISO9797Method2(outStream.toByteArray());
       
byte[] result = module.calculateMACISO9797Alg3(sKey, data);
       
System.out.println(ISOUtil.byte2hex(result));
   
}

I've also modified the JCESecurityModule a bit to get direct method access. The transaction data is valid (from a successful TIP-Test). I also have the application cryptogram (Tag 0x9F26), but the outcome from the code dosen't match the application cryptogram.

I'm working on a Java based EMV Level 2 Kernel, available at GitHub: https://github.com/AndreasFagschlunger/O2Xfs

The goal is know a card simulator which behaves like a real card for testing, and therefor I need my card to generate a valid cryptogram. The greater idea is to simulate all the TIP/ADV Testing cards and get the kernel tested automatically.

Mark Salter

unread,
Jan 14, 2015, 5:35:19 AM1/14/15
to jpos-...@googlegroups.com
On 14/01/2015 08:27, Billie wrote:
> I prefer code over specifications ;) This is my basic example, I have
> removed the Issuer Master Key:
Why remove the key, given that it is 'key' to the process and the test
result?

>
> |
> publicstaticvoidmain(String[]args)throwsException{
> byte[]amountAuhtorised =ISOUtil.hex2byte("000000001000");
> byte[]amountOther =ISOUtil.hex2byte("000000000000");
> byte[]terminalCountryCode =ISOUtil.hex2byte("0040");
> byte[]terminalVerificationResults =ISOUtil.hex2byte("8000048000");
> byte[]transactionCurrencyCode =ISOUtil.hex2byte("0978");
> byte[]transactionDate =ISOUtil.hex2byte("100514");
> byte[]transactionType =ISOUtil.hex2byte("01");
> byte[]unpredictableNumber =ISOUtil.hex2byte("2E13374C");
> byte[]applicationInterchangeProfile =ISOUtil.hex2byte("1800");
> byte[]applicationTransactionCounter =ISOUtil.hex2byte("0014");
> byte[]cvmResults =ISOUtil.hex2byte("020300");
>
>
> JCESecurityModulemodule=newJCESecurityModule("secret.lmk",BouncyCastleProvider.class.getCanonicalName());
> byte[]iMk =ISOUtil.hex2byte("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX");
> byte[]panpsn
> =JCESecurityModule.formatPANPSN("1234567890123456",null,MKDMethod.OPTION_A);
>
> System.out.println("PAN: "+ISOUtil.byte2hex(panpsn));
>
> Keykey =newSecretKeySpec(iMk,"DESede");
> KeyiccMk =module.deriveICCMasterKey(key,panpsn);
> System.out.println("iccMk: "+ISOUtil.byte2hex(iccMk.getEncoded()));
>
> KeysKey
> =module.deriveCommonSK_SM(iccMk,applicationTransactionCounter);
> System.out.println("sKey: "+ISOUtil.byte2hex(sKey.getEncoded()));
>
> ByteArrayOutputStreamoutStream =newByteArrayOutputStream();
> outStream.write(amountAuhtorised);
> outStream.write(amountOther);
> outStream.write(terminalCountryCode);
> outStream.write(terminalVerificationResults);
> outStream.write(transactionCurrencyCode);
> outStream.write(transactionDate);
> outStream.write(transactionType);
> outStream.write(unpredictableNumber);
> outStream.write(applicationInterchangeProfile);
> outStream.write(applicationTransactionCounter);
> outStream.write(cvmResults);
> outStream.write(ISOUtil.hex2byte("80"));
>
> byte[]data =module.paddingISO9797Method2(outStream.toByteArray());
> byte[]result =module.calculateMACISO9797Alg3(sKey,data);
> System.out.println(ISOUtil.byte2hex(result));
> }
> |
>
> I've also modified the JCESecurityModule a bit to get direct method
> access. The transaction data is valid (from a successful TIP-Test). I
> also have the application cryptogram (Tag 0x9F26), but the outcome from
> the code dosen't match the application cryptogram.

I was planning to see and match your result/output step for step to
highlight the issue/differences, without either the key, your result (I
could and would run the complete code) and the 'real' ARQC I can't
easily and would need to use a test example of my own which is more work.

Can you not share the full picture so helping you find your problem is
'easy'?


--
Mark

Billie

unread,
Jan 14, 2015, 5:59:36 AM1/14/15
to jpos-...@googlegroups.com
Hi Mark!

I found the key in an publicly available document:

https://www.paypass.com/TIP/PayPass_MTIP_UserGuide_USmarket_July2014.pdf

It's found on page 365, 7.2 DES Keys, first Key (IMK for ARQC). So here's the key and PAN:

byte[] iMk = ISOUtil.hex2byte("9E15204313F7318ACB79B90BD986AD29");
byte[] panpsn = JCESecurityModule.formatPANPSN("5413330089010012", null, MKDMethod.OPTION_A);

And the expected result, Tag 0x9F26 Application Cryptogram is: 4B68C1D3849032C7

Mark Salter

unread,
Jan 14, 2015, 6:10:42 AM1/14/15
to jpos-...@googlegroups.com
On 14/01/2015 10:59, Billie wrote:
> I found the key in an publicly available document:
>
> https://www.paypass.com/TIP/PayPass_MTIP_UserGuide_USmarket_July2014.pdf
>
> It's found on page 365, 7.2 DES Keys, first Key (IMK for ARQC). So
> here's the key and PAN:
>
> |
> byte[]iMk =ISOUtil.hex2byte("9E15204313F7318ACB79B90BD986AD29");
> byte[]panpsn
> =JCESecurityModule.formatPANPSN("5413330089010012",null,MKDMethod.OPTION_A);
> |
>
And this is the MDK that was embossed and used by a plastic - or a
simulator for the exchange you are trying to match?

> And the expected result, Tag 0x9F26 Application Cryptogram is:
> 4B68C1D3849032C7

Thanks for sharing the needed detail. I will work this example and
compare my results to the 'real' and yours, but I can't do this right
now, but I will try to do it shortly.


--
Mark

Mark Salter

unread,
Jan 15, 2015, 4:56:42 AM1/15/15
to jpos-...@googlegroups.com
On 14/01/2015 11:09, Mark Salter wrote:
> Thanks for sharing the needed detail. I will work this example and
> compare my results to the 'real' and yours, but I can't do this right
> now, but I will try to do it shortly.
Can you share your output - this will save me changing my local version
of the supporting classes to provide the method calls you are making.

Ta

--
Mark

Billie

unread,
Jan 15, 2015, 5:07:43 AM1/15/15
to jpos-...@googlegroups.com
I get 4abeb01ea40719dc as Result?

Mark Salter

unread,
Jan 15, 2015, 6:39:47 AM1/15/15
to jpos-...@googlegroups.com
On 15/01/2015 10:07, Billie wrote:
> I get 4abeb01ea40719dc as Result?
I was after all of the output from your run of the code, so I can check
each step?


--
Mark

Billie

unread,
Jan 15, 2015, 7:05:32 AM1/15/15
to jpos-...@googlegroups.com
Here it goes:

PAN: 1333008901001200
iccMk
: 4ac445704620c12ab954492f6e5e5efd4ac445704620c12a
sKey
: a8fb5816453b8392f13885c72604ecc4a8fb5816453b8392
4abeb01ea40719dc

Mark Salter

unread,
Jan 18, 2015, 8:26:56 AM1/18/15
to jpos-...@googlegroups.com
On 15/01/2015 12:05, Billie wrote:
> Here it goes:
>
> |
> PAN:1333008901001200
> iccMk:4ac445704620c12a b954492f6e5e5efd 4ac445704620c12a

I match this UDK-A/B component, but why is the UDK-A repeated here - it
is not needed?

> sKey:a8fb5816453b8392 f13885c72604ecc4 a8fb5816453b8392
Here we differ again your result is too long and I can't match on VSDC,
MCHIP or EMV2000.

I get:-

VSDC 4ac445704620c12ab954492f6e5e5efd
MCHIP 57cdae73d0257caea14c167594495b0e
EMV2000 dbb3b2b715bee2b6e68d9ac6518975a4

Can you share which algorithm you are trying to replicate? From the code
it seems to be MChip, but is that wanted?

I suspect here is where your difference starts.

> 4abeb01ea40719dc
What is this value ?


I think your CVR data should include the length too, making it 03020300
instead of just 020300.

I can't discern if you have shared the ARQC that was presented by the
card (or sim) yet, but I get :-

VSDC 35b8cf9289519754
MCHIP 39769b06ba3d2b04
EMV2000 6085fb6be36a9af8

In case you do get that far to be able to compare.

If none of the above ARQCs match your card's (or the simulator - as I
don't yet know what produced the ARQC you are tying to recreate) result,
then it is time for you to check the keys in use in the original, and
the PAN sequence number. Perhaps share the original test transaction in
full - broken down into the data components too; and of course all data
relevant to the test (I'm just not sure I have pulled each part out and
back together as it is spread across multiple messages; a single post
with all of the relevant test data might help.

Can you also share the hex dump of data[] as produced here :-

byte[] data = module.paddingISO9797Method2(outStream.toByteArray());

too please in case that is already padding (and you are getting extra
data as you are adding the x'80' manually.

--
Mark

Billie

unread,
Jan 19, 2015, 5:15:02 AM1/19/15
to jpos-...@googlegroups.com
Hy Mark!

The UDK-A repeats because jPos creates a 16 Bit 3DES Key-Object. The default JCE Provider from Java doesn't support 16 Byte 3DES Keys, you need at least 24 Bytes. So you append the first 8 bytes of the key to generate a valid 3 DES Key. But I'm using the Bouncy Castle Provider, which can handle 16 Bytes 3 DES Keys and does this automatically. If you remove the BouncyCastleProvider reference, a java.security.InvalidKeyException will be thrown.

The data I provides comes from an M/Chip. Is it supposed that on VSDC the iccMk and sKey are the same? As I tried to reproduce your sKey's, if matched your VSDC-Key by changing my code to the following:

        // Key sKey = module.deriveCommonSK_SM(iccMk, applicationTransactionCounter);
       
Key sKey = module.deriveSK_VISA(iccMk, applicationTransactionCounter);
       
System.out.println("sKey: " + ISOUtil.byte2hex(sKey.getEncoded()));

The output ist now

sKey: 4ac445704620c13eb954492f6e5ea1164ac445704620c13e

Which matches your sKey but is identical to the iccMk.

I suggest we focus first on generating the sMk for M/Chip. As you can see I use the org.jpos.security.jceadapter.JCESecurityModule#deriveCommonSK_SM-Method from jPos to generate the sKey. The first parameter is the iccMk-Key-Object, the second the ATC (0x0014).


Key sKey = module.deriveCommonSK_SM(iccMk, applicationTransactionCounter);

Is anything wrong here, does M/Chip use another random-Value than ATC since the rest comes from jPos.

A note to the output values, the expected Application Cryptogram is 0x4B68C1D3849032C7 (generated by M/Chip TIP Test card), 0x4abeb01ea40719dc is the (wrong) result my program generates. Here's the Hex-Dump of the transaction data as requested:

Data (before paddingISO9797Method2): 000000001000000000000000004080000480000978100514012e13374c1800001402030080
Data (after paddingISO9797Method2):  000000001000000000000000004080000480000978100514012e13374c1800001402030080800000

Hope you find some useful information.

Mark Salter

unread,
Jan 19, 2015, 12:55:30 PM1/19/15
to jpos-...@googlegroups.com


On Monday, January 19, 2015 at 10:15:02 AM UTC, Billie wrote:
A note to the output values, the expected Application Cryptogram is 0x4B68C1D3849032C7 (generated by M/Chip TIP Test card), 0x4abeb01ea40719dc is the (wrong) result my program generates. Here's the Hex-Dump of the transaction data as requested:

Data (before paddingISO9797Method2): 000000001000000000000000004080000480000978100514012e13374c1800001402030080
Data (after paddingISO9797Method2):  000000001000000000000000004080000480000978100514012e13374c1800001402030080800000


I think here might be the problem (or part of it).  You can see that after padding an additional '80' has been added as well as rounding to a multiple of 8 bytes;  this means that you do not need to add your own x'80' padding as the function takes care of that for you, so remove the line of code that adds the 80 and try again?

Have you confirmed that you have the correct MDK the test plastic (or simulator) used to produce the ARQC you are trying to match;  this must be the next step after removing the 'manual padding'.

--
Mark

Billie

unread,
Jan 23, 2015, 10:28:18 AM1/23/15
to jpos-...@googlegroups.com
The only thing I can confirm is that the mentioned IMK is the one described in the TIP User Guide, "It should be programmed in the network simulator for online cryptograms". The transaction was approved, the particular test case was successful. So it should be the right IMK, but I don't know it for sure because I only have the card data.

Removing the manual padding just resolved into another cryptogram, which doesn't match the expected one.

e29db34f0be7d44e != 4B68C1D3849032C7


Robert Demski

unread,
Jan 23, 2015, 5:58:13 PM1/23/15
to jpos-...@googlegroups.com

W dniu poniedziałek, 12 stycznia 2015 09:19:51 UTC+1 użytkownik Billie napisał:
Hello!

Does anyone know the algorithm VISA and MasterCard uses to generate the ARQC? I know they have different algorithms, and I didn't find anything detailed enough the verify a generated ARQC. For example, http://www.emvlab.org/cryptogram/ provides an online form - but the result dosen't match. It may be that I had the wrong values for transaction data, but there is also no option for the algorithm. I've also tried the Thales Simulator, but the Implementation seems broken. The JCESecurityModule in jPOS doesn't implement the verifyARQCImpl-Method, but that's exactly what I'm looking for.

Best regards
Billie

Mark Salter

unread,
Jan 24, 2015, 2:17:36 PM1/24/15
to jpos-...@googlegroups.com
On 23/01/2015 15:28, Billie wrote:
> The only thing I can confirm is that the mentioned IMK is the one
> described in the TIP User Guide, "It should be programmed in the network
> simulator for online cryptograms". The transaction was approved, the
> particular test case was successful. So it should be the right IMK, but
> I don't know it for sure because I only have the card data.
Card data - that which is in the authorisation message - can you share
that in full?

>
> Removing the manual padding just resolved into another cryptogram, which
> doesn't match the expected one.
Did you also adjust the CVR data component as I suggested?

Perhaps start over, share each input and output so that you have the
full story presented here?

--
Mark

Billie

unread,
Jan 27, 2015, 4:52:15 AM1/27/15
to jpos-...@googlegroups.com
I checked out the code from Robert Demski, I made a demo with the data from the JUnit-Tests and it matches. However, my MChip TIP-Test data doesn't work, also with VISA ADVT data I didn't get a match.

Here is the P55-Data from MChip:
iMK: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
PAN
: 5413330089010012
820218008407A0000000041010950580000480009A031005149C01015F2A0209789F02060000000010009F090200029F10120212A0000F240000000000000000000000FF9F1A0200409F1E0833533459524D56469F26084B68C1D3849032C79F2701809F33036040209F34030203009F3501149F360200149F37042E13374C9F41030015209F53015A



Here P55-Data for VISA:
PAN: 4761739001010176
MDK A
: 2315 208C 9110 AD40
MDK B
: 2315 208C 9110 AD40
820208008407A0000000031010950580800080009A031002239C01015F2A0209789F02060000000010009F090201409F100706000C03A010009F1A0200409F1E0833533459524D56469F26086E32F3724A2EDE179F2701809F33036040209F34033F00009F3501149F360200069F37043F2C0E4F9F4103000188



One thing I noticed, the CVR I originally provided (020300) is wrong - 020300 are the CVM results. The CVR should be encoded in the Issuer Application Data (9F10), but I don't know how exactly. I tried some variants, but still no match. Maybe we are missing some information to reproduce the ARQC.

Mark Salter

unread,
Jan 27, 2015, 11:26:49 AM1/27/15
to jpos-...@googlegroups.com
The CVR/CVM certainly won't have helped :-) .

Can you confirm:-

- that the PAN sequence number is 00 (P-23)
- the clear MDK for the 541333 again please?

As you have P-55 below, given the confirmation above, I should be able to match the ARQC.

I am just checking 476173 now.

-- 
Mark

Billie

unread,
Jan 27, 2015, 4:12:04 PM1/27/15
to jpos-...@googlegroups.com
Yes, PAN sequence number is "not present", so 00.

And the clear Issuer Master DES Key for the MChip card with PAN 5413330089010012 should be, according to the documentation, the following:

Robert Demski

unread,
Jan 28, 2015, 5:51:25 PM1/28/15
to jpos-...@googlegroups.com

From VSDC spec
The coding of Issuer Application Data is described in Appendix A, VIS Data Element Tables. For Cryptogram Version Numbers 10
and 18 (CVN 10 and CVN 18), it contains the following data concatenated in the order specified:
  • (1 byte) Length Indicator
  • (1 byte) Derivation Key Index (DKI)
  • (1 byte) Cryptogram Version Number
  • (4 byte) Card Verification Results (CVR)
  • (rest if any) Issuer Discretionary Data (optional)
The length indicator, DKI, Cryptogram Version Number, and CVR are mandatory, while the Issuer Discretionary Data is optional.

In your case you have following IAD:
9F100706000C03A01000
Its mean:

9F10 07
       
06 - length indicator
       
00 - deriv. key index
       
0C - CVN12 :(
       
03A01000 - 4 CVR bytes

Unfortunately used here was custom CVN12:
CVN 12 and CVN 50 through 59 have been made available to designate issuer proprietary cryptogram processing. They may be used by issuers that do not wish to implement the key management or issuer host authentication processing associated with CVN 10 or CVN 18 in the early stages of migration, or by issuers that want to support an issuer-proprietary cryptogram.
Commonly used for VSDC are CVN10 and CVN18 where for ARQC verification:
  • CVN10 use SKDMethod.VSDC rules (EMV 3.1.1) padded with zeros
  • CVN18 use SKDMethod.EMV_CSKD rules (EMV 4.X) padded with 80 and zeros
Try CVR as '03A01000'

Billie

unread,
Jan 29, 2015, 2:49:29 AM1/29/15
to jpos-...@googlegroups.com
"issuer-proprietary", so it might be possible that the algorithm used for generating the ARQC isn't VSDC standard and without the proper information, we couldn't reproduce the ARQC. With my MChip data it may be the same issue.

Billie

unread,
Jan 29, 2015, 4:22:51 AM1/29/15
to jpos-...@googlegroups.com
Due to the post of Robert Demski I started to search for a transaction with a different CVN (0x0A) in it's issuer application data. And voilà! I did get a match for VSDC. So I can confirm the Roberts code is working correct and with the jPOS sources I should be able to simulate a VSDC card.

Does anyone have details for the MChip Issuer Application Data? Maybe there are also different cryptogram versions.

Robert Demski

unread,
Jan 29, 2015, 11:00:19 AM1/29/15
to jpos-...@googlegroups.com
The code must work, because it is tested with the real test cards M/Chip, VSDC (CVN10, CVN18).
ARQC were tested, ARPC and MAC generation scripts and pin-block encryption for pin change. Included JUnit tests are correct and verified by HSM.
The only problem that can occur is to call these functions. The appropriate parameters, options and padding

Issuer Application Data for M/Chip Select 4
  • (1 byte) Key Derivation Index
  • (1 byte) Cryptogram Version Number
  • (6 bytes) Card Verification Results
  • (2 bytes) DAC/ICC Dynamic Number
  • (8 bytes) Plaintext/Encrypted Counters (optional)
For M/Chip use 80 + zeroes padding for data. Try with SKDMethod.MCHIP
In your case IAD is:
9F10120212A0000F240000000000000000000000FF
its means:
9F10 12
       
02                - Key Derivation Index
       
12                - Cryptogram Version Number
       A0000F240000      - Card Verification Results
       0000              - DAC/ICC Dynamic Number
       00000000000000FF  - Plaintext/Encrypted Counters

Try CVR: 'A0000F240000'

Marcos Brienze

unread,
Feb 16, 2017, 7:40:00 AM2/16/17
to jPOS Users


Hi guys, 

I´m developing a simulator software for a great company in Brazil and I´m facing some lack of information from the depto who has hired me to develop the SW. 
I need some support from you, because I am running out of ideas to overcome the following issue. 

One of the information is about the cryptogram version in order to guide me to the methods for ICC Master Key and Session Key derivations. 
From the message request I got the following IAD (9F10): 

'0FA501A030F8000000000000000000000F000000000000000000000000000000' 

My reasoning is that according to the IAD, whose format is A, the cryptogram version is 5, and therefore I infer from the EMV 4.2 Book 2 (Annex A1.4) I should use the methods described there to derive MKac and SKac. 
Am I right about my interpretation of the IAD ? Is the cryptogram version 5 ? 

I´ve been using BP-Tool to help me to calculate ARQC and I´ve already chosen EMV 4.2 method to calculate it, but I haven´t it got right yet. The ARQC calculated is different from 9F26. 
I don´t know which variables are wrong: method to derive the keys, IMKac, or data. My first step is having the method surely clarified, then I will skip to the next doubt until get the ARQC done. 

My idea would be start coding and using JPOS library when I fill the gaps. 

Thanks a lot and I´d appreciate any comments or ideas. 

Marcos 

Mark Salter

unread,
Feb 16, 2017, 6:57:59 PM2/16/17
to jpos-...@googlegroups.com
On 16/02/17 12:40, Marcos Brienze wrote:
> Thanks a lot and I´d appreciate any comments or ideas.
This is an old thread - start a new one is best.
Your question is Off Topic here, but mark it OT in the subject and that
will allow those that care to filter.

Check the commercial license that your client will need; make sure the
company are aware of your/their obligations.

good luck

--
Mark

Sandile

unread,
Oct 25, 2018, 10:55:02 AM10/25/18
to jPOS Users
Hi
Please help me on how to calculate ARQC with this data.

Sandile

unread,
Oct 25, 2018, 10:57:38 AM10/25/18
to jPOS Users
Hi
Can you please give me guidance on how fill in this data
Reply all
Reply to author
Forward
0 new messages