Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add Application Cryptogram Spec #499

Merged
merged 4 commits into from
Oct 19, 2022
Merged

Conversation

rainer010
Copy link
Contributor

@rainer010 rainer010 commented Oct 19, 2022

Quick summary

In an online authorization scenario, an ARQC (Authorization ReQuest Cryptogram ) is generated on the card chip, forwarded to the card scheme, and later validated by the Issuer. To perform an adequate validation, the issuer needs to consider:

  • different cryptogram algorithm (versions)

  • a different collection of data that might be part of the cryptogram

This PR aims to create a set of components that could simplify the process of validating an ARQC and generating the adequate ARPC (Application Response Cryptogram) in a version-agnostic approach.

Implementation details

We are proposing a set of java components that could be able to:

  • Validate the cryptogram with a version-agnostic approach.

  • Automatically detect the cryptogram version (particularly useful for environment where several cryptogram version might coexist).

  • Give flexibility to the set of data elements used for the cryptogram validation.

These requirements could be better appreciated in this sample code:

ISOMsg request = ...;
ISOMsg response = ...;
TLVList tlv = parse(request.get(55));
IssuerApplicationData iad = new IssuerApplicationData(tlv.getString(0x9f10));
CryptogramSpec spc = iad.getCryptogramSpec();
CryptogramDataBuilder dataBuilder = spc.getDataBuilder();

boolean isValid = hsm.validateARQC(spc.getMKDMethod(), spc.getSKDMethod(), f55.getString(0x9f26), ..., dataBuilder.buildARQCRequest(tlv, iad)); 
if (isValid) {
   String arpcRequest = spc.getDefaultARPCRequestData(true);
   String arpc = hsm.generateARPC(spc.getMKDMethod(), spc.getSKDMethod(), f55.getString(0x9f26), ..., arpcRequest);

   TLVList responseTLV = new TLVList();
   responseTLV.put(0x9f10, arpc + arpcRequest);
   response.set(55, serialize(responseTLV));
} else { 
   response.unset(55);
   response.set(39, INVALID_ARQC);
}

To cover these requirements, the following changes are added:

  • Interfaces are added to generically represent the different cryptogram generation algorithms. Additionally, an interface is created that represents the set of data used by the different algorithms to generate the cryptogram.

  • Specification of the application cryptogram generation algorithm used by M/Chip and VISA are added.

  • Support to detect the specifications of the cryptogram generation algorithm is added, It is using the format and CVN information contained in IAD.

The different implementations (versions) of the application cryptogram
generation algorithm differ in 4 points: the master key derivation
method, the session key derivation method, the data elements used and
the generation method of the response cryptogram.

To create components that can generate and validate the application
cryptograms in a generic way, we need a mechanism to specify the
particularities of the different algorithm.

Interfaces are added to generically represent the different cryptogram
generation algorithms of the application. Additionally, an interface is
created that represents the set of data used by the different
algorithms to generate the cryptogram.
Mastercard has used two versions of the application's cryptogram
generation algorithm, each of these versions has its variants.

We need to specify (including the particularities) the application
cryptogram generation algorithm used by M/Chip so that the generic
components (SM) in charge of generating and validating the cryptogram
can correctly perform their task.

Specification of the application cryptogram generation algorithm used
by M/Chip is added, this covers the different versions and existing
particularities.
Visa uses several versions of the application cryptogram
(CVN 10, 18 and '22' ), each version has its own peculiarities.

We need to specify the different versions of the application cryptogram
generation algorithm used by VISA so that the generic components (SM)
in charge of generating and validating the cryptogram can correctly
perform their task.

The specification of the cryptogram generation algorithm of the
application used by VISA is added, this specification covers all
versions and particularities.
The IAD contains application data, among these data is
CVN (Cryptogram version number), this data indicates the version of
the algorithm used to generate the cryptogram.

In environments where several versions of the application cryptogram
coexist, we need to automatically detect the specifications of the
algorithm used to generate the current cryptogram.

Support is added to detect the specifications of the cryptogram
generation algorithm, using the format and CVN information contained
in IAD.
@ar ar merged commit 012df45 into jpos:master Oct 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants