| Table of Contents |
|---|
A physical model (or deployment model) is a representation explaining which physical modules are installed on nodes.
...
Depending on the platform, the components below might be compiled in a single binary, a.k.a the “firmware”.
Compilation
The compilation is the step required to generate binaries. Depending on the platform OS, there are 2 alternate possibilities:
...
In any alternative, use Symbols, Options, and Constants to define which options fit to the target.
Deployment View
...
Beyond the data model and the underlying persistent files, there are 3 other data files used by Agnos Framework to support specific EMV features:
CAKeys in order to support ODA (SDA, DDA, and CDA)
CRL in order to support revocated keys
EFL in order to support exception files list (not EMV related however)
...
Following data are used only when EMV ODA is supported (for offline card authentication). These files are usually retrieved from acquirer’s or processor's host and transportation format is always specific. File format as described below presents how information shall be persisted in the terminal in order to allow Agnos library to work as designed. Related GPI primitive (see HSM/cacertificates.c/gpiGetEMVCertificate) may be overloaded to support a specific format different from the one below. For example, CAKeys file may be split up into different files sorted by RID.
...
Field
...
Format
...
Description and Rule
...
Example
...
RID
...
unsigned char[5]
...
As per networks definition
...
First bytes from an AID as per ISO definition
...
Index
...
unsigned char
...
As per networks definition
...
Aligned on EMV tag 8F
...
ExponentLength
...
unsigned char
...
X
...
0x01 or 0x03 as per EMV specifications
...
KeyLength
...
unsigned char
...
N
...
Max 248 bytes as per EMV specifications
...
Exponent
...
unsigned char[X]
...
See RSA calculation
...
n/a
...
Modulus
...
unsigned char[N]
...
See RSA calculation
...
n/a
Note: Concerning the transportation format, there is an additional 20 byte SHA-1 trailing at the end of the keys (when keys are received from ACE). But, this integrity trailer is not stored into CAKeys file.
Revocated Keys Format (CRL file)
Following data are used only when CRL is mandatory. This file is usually retrieved from acquirer’s / processor's host and transportation format is always specific. File format as described below presents how information shall be persisted in the terminal in order to allow Agnos library to work as designed. Related GPI primitive (see HSM/cacertificates.c/gpiGetEMVCRL) may be overloaded to support a specific format different from the one below.
...
Field
...
Format
...
Description and Rule
...
Example
...
RID
...
unsigned char[5]
...
As per networks definition
...
n/a
...
Index
...
unsigned char
...
As per networks definition
...
n/a
...
SerialNumber
...
unsigned char[3]
...
As per networks definition
...
n/a
Exception File List Format (EFL file)
Following data are used only when EFL is mandatory. This file is usually retrieved from acquirer’s / processor's host and transportation format is always specific. File format as described below presents how information shall be persisted in the terminal in order to allow Agnos library to work as designed. Related GPI primitive (see HSM/cacertificates.c/gpiFindPANFromEFL) may be overloaded to support a specific format different from the one below.
...
Field
...
Format
...
Description and Rule
...
Example
...
PSN
...
unsigned char
...
As per networks definition
...
n/a
...
PAN Length
...
unsigned char
...
X
...
n/a
...
PAN
...
unsigned char[X]
...
As per networks definition
...
n/a
Applications File (apps file)
When Agnos Framework uses the dynamic library loading mechanism, all libraries shall be copy to /AGNOS directory. From there, a specific file (apps) must be modify to declare which CL kernels the system supports. Here is the format:
...
Example of an apps file supporting 2 CL kernels (Mastercard + Visa):
| Code Block |
|---|
2 |
...
libC2.so |
...
libC3.so |