Amadis

GPI/DEVICE Integration

 

The GPI integration is the very first step to realize in order to integrate Agnos Framework on any device. The GPI is made of:

  • An interface, i.e. a set of .h header files. Header files represent the software contract between Agnos Framework and any platform. It shall not be modified

  • A behaviour, i.e. a set of .c files implementing headers

 

Since AGF 3.3.x version, a new abstraction layer has been added to simplify the GPI porting: DEVICE. Now, all the realization for the porting shall be done in that DEVICE layer:

 

 

Important:

  1. A DEVICE implementation shall be conducted along with Unit testing. It is not recommended to enter into Debug or TA sessions without a formal testing plan completed with success. The GPI/DEVICE combination must be tested separately from its integration to Agnos Framework to avoid long and fastidious debugging times

  2. Since AGF 3.3.x, the GPI layer shall not be modified

  3. GPI/DEVICE integration has to be performed in parallel with ACE integration (or with a similar SDK)

  4. In the DEVICE, following extracted section is provided to help developers to insert their own implementation:

/////////////////////////////////////////// // !!! Code here your platform API call !!! /////////////////////////////////////////// /////////////////////////////////////////// // End ///////////////////////////////////////////

 

GPI Testing System (GTS)

See GTS page.

GPI Functional Coupling

See GPI Functional Coupling page.

GPI Languages, Strings, and Lists Management

See GPI Languages, Strings, and Lists Management page.

GPI Primitives References

See GPI Primitives References page.

 

  • GPI/DEVICE’s Platform module provides a set of services related to the device’s operating system functions like file management, real time clock, shared memory, etc… It also integrates administrative services like gpiMain to provide flexible mechanisms for initialization and system’s release. See gpi.h, and gpiplatform.h

 

  • GPI/DEVICE’s CAD module provides a set of services related to the communication with contact/contactless card. See gpicad.h

 

  • GPI/DEVICE’s HSM module is ready to be used. It can be compiled as is if there is no need to use hardware cryptographic primitives. Nevertheless, it’s possible to map the following services to a hardware API:

    • gpiSHAInit

    • gpiSHAUpdate

    • gpiSHAFinal

    • gpiRsaComputation

    • gpiGetRandomNumber

 

Note: Agnos random generation algorithm is used to generate UN (tag 9F37), and UNNumeric (tag 9F6A for MasterCard PayPass). It is implemented as following:

  1. Get 4 random numbers between 0 and 255

  2. Perform a SHA on these 4 numbers

  3. Get 4 numbers from SHA result

If the platform has no RTC, be careful on the entropy used to generate the seed.

 

  • GPI/DEVICE’s SPED module provides a set of services related to pin entry (offline and/or online) and cardholder choices (application selection, language selection, etc…). That module comes with a full functional and certified code that may be used as is. However, depending on the security architecture that code might be ported on a specific secured hardware part or replaced with an existing platform’s API service. A special attention shall be drawn to:

    • Online pin management. Encipherment is not standard. For the purpose of kernel certifications, the GPI uses ISO – format 0

    • Offline pin management. It may be designed in multiple ways. Keep in mind that the pin has to be used in clear at some point during the card processing. Hence, verify/get data APDU commands and RSA computation shall be deployed at the same level of security

    • Display is part of GPI’s SPED modules. Some of the recent platform do not support that feature. In that situation, it is important to validate whether such a system can be deployed in targeted regions/merchants.

 

 

GPI Special Notes

GPI Polling

See GPI Polling page.

GPI Antenna Management

See GPI Antenna Management page.

GPI Performance

See GPI Performance page.