Agnos Framework requires a specific deployment, and different physical components to be able run on an embedded device or any other systems. Each component below is a binary file that has a version and a corresponding code management under a version control system. Test Application - Kizis - is not part of the released product but delivered as an example to get L2 LoAs and to help the L3 development.
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:
Either the OS supports dynamic library loading
Either the OS only supports static compilation units
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)
Public Keys Certificates Format (CAKeys file)
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:
<apps> ::= <header><separator><list_of_applications>
<header> ::= <digit>|<integer><digit>
<digit> ::= “0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9”
<separator> ::= <LF><CR>
<LF> ::= 0ah
<CR> ::= 13h
<list_of_applications> ::= {<application>}|<list_of_applications>
<applications> ::= <text><extension>
<text> ::= <character><text>
<character> := “A” | “B” | “C” | “D” | “E” | “F” | “G” | “H” | “I” | “J” | “K” | “L” | “M” | “N” | “O” | “P” | “Q” | “R” | “S” | “T” | “U” | “V” | “W” | “X” | “Y” | “Z” | “a” | “b” | “c” | “d” | “e” | “f” | “g” | “h” | “i” | “j” | “k” | “l” | “m” | “n” | “o” | “p” | “q” | “r” | “s” | “t” | “u” | “v” | “w” | “x” | “y” | “z” | <digit>
<extension> ::= “.so” | “.dll”
Example of an apps file supporting 2 CL kernels (Mastercard + Visa):
2
libC2.so
libC3.so