Skip to content

Security 🔒

Security is not covered by EMV Level 2 requirements in a sense that there is no tests performed against sensitive data protection, confidentiality, integrity, key management, penetration, etc... But: - EMV does implement a scheme based on public keys called Offline Data Authentication (see EMVCo Book II for more details). This mechanism is widely addressed by payment networks' test plans. It aims at authenticating cards offline. - EMV also includes a secret key based cryptography but the terminal is not involved on that part (other than relaying the information between the card and the issuer host). A card embed secret keys that are derived per transaction, and used to sign data so an issuer can authenticate it. And conversely. This is called Online Mutual Authentication (OMA).

That being said, switstack moka has been designed so integrators facing PCI's security requirements to certify their final solution have minimum job to accomplish. The idea is to encapsultate any EMV Level 2 functional processing requiring sensitve data into a dedicated module. This modules stores, obsucates, and manipulates any information subject to PCI assessment and used as an input to EMV Level 2 computation.

Offline Data Authentication (ODA)

ODA is an EMV mechanism used to authenticate cards offline. It includes SDA, DDA, CDA, and XDA. Along with OMA (Online Mutual Authentication), it realizes the EMV security scheme. Whereas OMA is based on symmetric cryptography, ODA uses RSA and ECC keys to perform offline authentication.

Note

RSA (Rivest, Shamir, Adleman) is the EMV's legacy algorithm. ECC (Elliptic Curve Cryptography) is now proposed from EMVCo Book IV, v4.4 and EMVCo Book C-8.

You may also refer to EMVCo Book II that describes the security scheme and underlying key organization.

In line with switstack's strategy to protect sensitive data, ODA implementation has been addressed with "PCI requirements" in mind. The challenge that ODA offers in regards to data protection is:

  1. Some ODA certificates contains the card's PAN or a portion of it;
  2. EMV Level 2 kernels need to manipulate these certificates;
  3. EMV Level 2 kernels need to sort card's read records containing sensitive data and participating to ODA.

On the other hand, ODA validation may require specific logics beyond the EMV Level 2 standard specifications. So, moka needs to offer maximum flexibility to implement, as an example, transit logic (i.e. for open payment) using contactless EMV acceptance to manage users accesses to transportation networks and the corresponding fees calculation.

So, that's why ODA implementation is supported by 3 different moka services:

  1. CPA: verifies static signed data certificate (tag 93) and signed dynamic application data (tag 9F4B) in the limits of sensitive data protection;
  2. Reader: verifies issuer's and icc's certificates. Also, performs all operations involving sensitive data such as signed record hashing, PAN comparison, etc...;
  3. HSM: stores all ODA keys and manages revocations.

Additionally, these components use an EMV tool box that is a static library. That static library is stateless (doesn't store any data). But, it may see sensitive information during ODA process. So, depending of the physical architecture, that library shall have 2 instances: 1 running alongside CPA services (at application level); 1 running alongside the Reader service.

Issuer Certificate (tag 90) ICC Certificate (tag 9F46) Static Signed Data (tag 93) Signed Dynamic Application Data (tag 9F4B)
Validated by Reader Service Reader Service CPA Service CPA Service
Require expiration date control Yes Yes No No
Require revocation control Yes No No No
Require PAN Manipulation Yes (PAN prefix) Yes No No
Require Signed Records Manipulation No Yes Yes No
May include Proprietary Format No Yes Yes Yes

Thanks to switstack moka architecture, these 3 components may be deployed in a secure zone whereas the core of EMV Level 2 processing may run on the application processor.

Sensitive Data Protection

Sensitive data management is meant to avoid the dissemination of the senstive information accross the EMV Level 2 code. In switstack moka's architecture, this is the role of the Reader service in collaboration with the HSM (which stores certificates and revocated certificates). switstack moka - Reader service

Note

For a better readability, the model above doesn't represent the message broker but all services communicate through it.

Reader

Data model

The list of protected data is made of the following tags:

typedef struct moka_signed_record {
    /** Record data. */
    uint8_t value[HAL_MAX_APDU_LENGTH];
    /** Record length. */
    uint16_t length;
} moka_signed_record_t;

typedef struct moka_signed_records_container {
    /** Number of records. */
    uint8_t number_of_records;
    /** Length of records. */
    uint16_t length;
    /** Records. */
    moka_signed_record_t record[MAX_SSAD_RECORD];
} moka_signed_records_container_t;

typedef struct moka_sred_data {
    /** track 2 equivalent data */
    uint16_t _57_length;
    uint8_t _57[19];
    /* application pan */
    uint16_t _5A_length;
    uint8_t _5A[20];
    /* df name */
    uint16_t _84_length;
    uint8_t _84[16];
    /* ca public key index */
    uint16_t _8F_length;
    uint8_t _8F[1];
    /** issuer public certificate */
    uint16_t _90_length;
    uint8_t _90[READER_SRED_MAX_KEY_LENGTH];
    /** issuer public remainder */
    uint16_t _92_length;
    uint8_t _92[READER_SRED_MAX_KEY_LENGTH];
    /** transaction date */
    uint16_t _9A_length;
    uint8_t _9A[3];
    /** cardholder name */
    uint16_t _5F20_length;
    uint8_t _5F20[26];
    /** issuer public key exponent*/
    uint16_t _9F32_length;
    uint8_t _9F32[3];
    /** icc public key certificate */
    uint16_t _9F46_length;
    uint8_t _9F46[READER_SRED_MAX_KEY_LENGTH];
    /** icc public key exponent*/
    uint16_t _9F47_length;
    uint8_t _9F47[3];
    /** icc public key remainder */
    uint16_t _9F48_length;
    uint8_t _9F48[READER_SRED_MAX_KEY_LENGTH];
} moka_sred_data_t;

// Instances
static moka_sred_data_t g_sred_data;
static moka_signed_records_container_t g_signed_records;
static uint8_t g_last_read_record[HAL_MAX_APDU_LENGTH] = "";
static uint16_t g_last_read_record_length = 0;

These data are encapsulated by the Reader service because it also manages the coupling with cards. During APDU exchanges, they are captured, obfuscated, and stored locally to the Reader service for further EMV Level 2 processing. Additionally, the service Reader exposes the following functional services to address EMV steps based on sensitive data:

Functional services

Reader Services Description
READER_SERVICE_GET_ISSUER_KEY Get issuer key for SDA processing
READER_SERVICE_GET_ICC_KEY Get icc key for CDA processing
READER_SERVICE_SET_SIGNED_RECORD Flag a record participating to offline data authentication
READER_SERVICE_GET_CAPK_INDEX_PRESENCE_STATUS Indicate whether a capk ined is present in certificate database
READER_SERVICE_STORE_RRP_IN_TRACK_2 Store discretionary data into track 2 equivalent data
READER_SERVICE_COMPARE_PAN Compare pan values from tag 57 and pan from tag 5A
READER_SERVICE_COMPUTE_SSD_SHA Perform SHA computing required to verify SDA certificate, tag 93
READER_SERVICE_EXTRACT_PAN_AND_EXPIRATION_DATE Extracts PAN and expiration date from track2 equivalent data

That way, all these information are never used outside the logic of the Reader service. This architecture principle limits the magnitude of the PCI zone, and - thanks to the message broker - enables simple realization of physical architectures that can leverage on a secure element, for example.