SoftPOS high Level Architecture exemple

EMV Kernel on SoftPOS Framework

The Agnos L2 SDK provides the way for the customer to :

• connect his Secure Client API (secclt module) that allows the merchants app to provision and control the attestation and monitoring, keys and configuration update, and PIN entry by …(KML2 Lib connected to ? )

• use and connect is L3 Payment application via The Agnos API (agnos module - OLA) that provides payment transaction features.

Notes:

• The Secure Client maintains its own connection with its backend. The system administrator must provide the required connection and authentication parameters to the SDK provisioning API.

• The Secure Client API and Agnos API are independent. If an online PIN verification is required, the L3 module is responsible for invoking the secure PIN entry API and send the resulting cryptogram to its servers. Est ce toujours le cas ?

Secure Backend

The Secure backend provides the following interfaces:

• The Secure Backend REST API is meant to be used only by the Secure Client and must be accessible from the internet.

• The administration REST API allows performing administration operations such as:

  • Managing device models.

  • Adding devices to the system.

  • Registering users.

• The remediation REST API allows the incident and fraud detection console operator to trigger an application specific remediation action in a specific application instance.

The Secure Backend consumes the following interfaces:

• The security incidents notification interface that sends the details of possible security issues detected in the deployed merchants’ applications.

• The cryptographic provider interface that exposes the cryptographic operations required by the Secure Backend.

Android COTS GPI HAL

GPI provides a wide set of primitives through the API level called Service Abstraction Level (SAL). This SAL layer encapsulates Agnos' HAL corresponding to the DEVICE layer. Integrating a new platform means overloading DEVICE behavior, i.e. coding into HAL. However, some GPI primitives may be overloaded depending on L3 needs:

• gpiInitializeHSM (*): overload it to modify file references (not required for L2 TA)

• gpiEMVGetCertificate (*): overload it to modify public keys look-up (not required for L2 TA)

• gpiGetEMVCRL (*): overload it to modify revocated certificates look-up (not required for L2 TA)

• gpiFindPANfromEFL (*): overload it to modify exception file parsing (not required for L2 TA)

Diagramme integration

Function:

Connect to

Open L2 API (OLA)

Diagramme integration

Function:

Connect to

Open L2 API interface is an abstraction of the card processing (alias L2. See also here More On Card Processing ), for EMV contact and EMV contactless systems. It is based on a simple set of primitives to ease L2 integration onto a payment application (alias L3).

That set of primitives supports Nexo Fast’s structures and dynamics.

What is not covered by OLA interface is:

• Pin pad management: refer to manufacturer’s SDK to integrated use cases related to pin entry. Most of the time, proprietary callbacks must be defined using specific software signatures

• Transit features: use manufacturer’s SDK to realize transit use cases. For example, if using Agnos Framework, refer to Callbacks API.

 Table to be updated