When we insert a bank card into a POS terminal or make a contactless payment, the terminal needs to assess whether the card in front of it can be trusted.
So how can a POS terminal tell that the card was really personalized by an authorized institution, and that its critical data hasn't been altered?
One of the answers is the Public Key Infrastructure (PKI) and digital certificate chain used in the EMV standard.
In EMV systems, we come across concepts such as the CA Public Key, the Issuer Public Key Certificate and the ICC Public Key Certificate.
These three components play an important role, particularly in the Offline Data Authentication (ODA) process.
In this post, we'll look at what these certificates are for, how they are created, how they are used during data preparation, and how the POS terminal verifies them.
1. The basics first: public and private keys
Before we can understand the EMV certificate chain, we need to know about asymmetric cryptography.
In asymmetric cryptography, there are two mathematically related keys:
- Public key: Can be shared, and can be used to verify digital signatures.
- Private key: Kept secret, and used to create the corresponding digital signatures.
Let's take a simple example.
Suppose an organization has a private key and public key pair.
The organization digitally signs some data using its private key.
Another system then verifies that signature using the corresponding public key.
A successful signature verification gives cryptographic assurance that the data was signed with that private key and that the signed content hasn't been altered.
But this raises a new problem:
How do we know that a public key really belongs to the right organization?
Solving that problem is the core purpose of the certificate chain.
2. What is a CA (Certificate Authority)?
A CA, or Certificate Authority, is the authority that reliably binds public keys to their owners through digital certificates.
In EMV payment systems, the CA role is tied to the certificate infrastructure of the relevant payment scheme.
For example, payment schemes such as Visa, Mastercard or TROY may each have CA key infrastructures managed according to their own requirements.
The CA's core job is to certify issuers' public keys with its own private key.
This lets the terminal use the CA's trusted public key to verify the validity of the issuer's public key.
The CA key pair
There are two keys on the CA side:
CA Private Key: The private key the CA uses to sign certificates, protected in a secure environment.
CA Public Key: The public key the terminal uses to verify the relevant issuer certificate.
The CA Private Key is never distributed to POS terminals or cards.
The CA Public Key, on the other hand, can be provided to terminals through the payment scheme's secure key distribution mechanisms.
The key point is this: the POS terminal's trust in the relevant CA Public Key is the starting point of the chain.
3. What is the issuer certificate?
The issuer is the financial institution that provides the customer with a debit or credit card.
The issuer may also have a key pair for asymmetric cryptographic operations:
- Issuer Private Key
- Issuer Public Key
For the terminal to trust the Issuer Public Key, it has to be certified by the CA.
In general, the process works like this:
Step 1: The issuer generates its own key pair in a secure environment.
Step 2: The Issuer Public Key and the data required for certification are submitted to the CA according to the payment scheme's procedures.
Step 3: The CA signs the issuer's public key data and the related certificate fields with its own private key.
Step 4: The result is the Issuer Public Key Certificate.
With this certificate, the terminal can verify the issuer's public key using the CA Public Key.
Where is the issuer certificate stored on the card?
In the classic RSA-based EMV offline authentication model, the Issuer Public Key Certificate is represented on the card by Tag 90.
The following fields may also be used:
| EMV Tag | Description |
|---|---|
| 8F | CA Public Key Index |
| 90 | Issuer Public Key Certificate |
| 92 | Issuer Public Key Remainder (when needed) |
| 9F32 | Issuer Public Key Exponent |
The terminal selects the right key using the application's RID and the CA Public Key Index.
4. What is the ICC certificate?
ICC stands for Integrated Circuit Card, which here means the chip card.
The ICC Public Key Certificate is the structure that certifies the card's public key with the issuer's digital signature.
This adds a third layer to the chain of trust.
The CA has certified the issuer's public key.
The issuer, in turn, certifies the card's public key.
So in the classic RSA-based EMV DDA/CDA model, the following relationship forms:
CA → Issuer → ICC
The ICC key pair
Cards that support dynamic offline authentication have an ICC key pair:
- ICC Private Key
- ICC Public Key
The ICC Private Key must remain secret and secure. Depending on the card platform and the secure personalization architecture, it can be generated on the card itself or in a suitable secure infrastructure.
The ICC Public Key is certified by the issuer.
The general process is:
Step 1: The ICC key pair required for the card is generated.
Step 2: The ICC Public Key enters the issuer's certification process.
Step 3: The issuer signs the required card and key data with its Issuer Private Key.
Step 4: The ICC Public Key Certificate is created.
Step 5: This certificate is loaded onto the card during data preparation and chip personalization.
In the classic RSA-based EMV model, the relevant fields are:
| EMV Tag | Description |
|---|---|
| 9F46 | ICC Public Key Certificate |
| 9F47 | ICC Public Key Exponent |
| 9F48 | ICC Public Key Remainder (when needed) |
This brings the card's public key into the chain of trust through the issuer's digital signature.
5. How are certificates prepared during card personalization?
Now let's look at the process from the point of view of a card production facility.
Imagine a bank is producing new cards.
The card's EMV profile, customer data and security requirements have already been defined.
From a certificate infrastructure perspective, the steps generally look like this.
Stage 1: The CA key infrastructure is in place
The payment scheme's CA keys were created beforehand.
CA Public Keys can be securely distributed to authorized terminal infrastructures.
The Issuer Public Key Certificate has been created through the CA's certification process.
None of this has to be redone from scratch for every card produced.
The same valid issuer key and certificate infrastructure can be used for many cards, within the applicable policy.
Stage 2: Preparing ICC keys
Depending on the offline authentication method the card must support, an ICC key pair may be needed.
In classic RSA-based applications that support DDA or CDA, the card must be able to create a dynamic signature with its own private key.
For this purpose, the ICC key pair is prepared securely.
Stage 3: Creating the ICC certificate
The card's public key, along with the related certificate data, goes through the issuer's signing process.
The ICC Public Key Certificate is produced using the Issuer Private Key.
The card's public key is now certified by the issuer.
Stage 4: Data preparation
The data preparation system assembles the EMV data the card needs.
This may include:
- Issuer Public Key Certificate
- ICC Public Key Certificate
- CA Public Key Index
- Public key exponents and, when needed, remainder fields
- The card's other EMV application data
Which data blocks or personalization commands carry this data depends on the card operating system, the payment application and the personalization solution.
Stage 5: Chip personalization
The prepared personalization data is transferred to the chip through appropriate secure channels and APDU commands.
At this stage, it is critical that the card's private key is stored securely and cannot be extracted without authorization.
Once personalization is complete, the card is able to provide the terminal with the certificates and signature data required by the offline authentication method it supports.
6. How does the POS terminal verify the certificate chain?
Now we've reached the most important part of the chain of trust.
When a customer inserts their card into a POS terminal, the terminal selects the relevant EMV application and reads the application data from the card.
Let's assume the transaction requires and supports offline data authentication.
Step 1: Finding the CA Public Key
The terminal uses the card's AID/RID and the CA Public Key Index value.
With these, it tries to find the matching CA Public Key in its own list of trusted CA keys.
If no matching CA key is found, the offline authentication method cannot complete successfully.
Step 2: Verifying the issuer certificate
The terminal reads the Issuer Public Key Certificate from the card.
It then cryptographically verifies the certificate using the CA Public Key.
Required checks are performed on the certificate's format, hash, expiry date and the related issuer data.
If verification succeeds, the terminal can reliably obtain the issuer's public key.
Step 3: Verifying the ICC certificate
In a classic RSA-based model using DDA or CDA, the terminal also reads the ICC Public Key Certificate from the card.
This time, verification uses not the CA Public Key but the Issuer Public Key verified in the previous step.
Integrity and validity checks are performed on the ICC certificate.
If the checks pass, the terminal obtains the ICC Public Key.
Step 4: Verifying that the card holds the private key
There's a critical distinction here.
A card presenting a valid ICC certificate does not, on its own, prove that it actually holds the corresponding ICC Private Key.
Showing that requires dynamic verification.
In DDA, the card can sign dynamic inputs, such as relevant transaction data and an unpredictable number supplied by the terminal, with its own private key.
The terminal then checks that signature with the ICC Public Key it verified.
If the signature verifies successfully, the terminal has cryptographic proof that the card can use the corresponding private key.
In CDA, dynamic signature verification is integrated with the generation of the application cryptogram.
This means the link between specific transaction data and the cryptogram produced by the card can also be verified.
7. What's the difference between SDA, DDA and CDA?
When we talk about EMV offline data authentication, there are three main methods.
SDA (Static Data Authentication)
SDA verifies that certain static data on the card was signed by the issuer.
The terminal verifies the Issuer Public Key via the CA Public Key, and then checks the Signed Static Application Data (Tag 93) with the Issuer Public Key.
With SDA, the card does not need to create a dynamic signature with its own ICC Private Key.
As a result, SDA alone does not provide DDA- or CDA-level protection against the card being cryptographically cloned.
DDA (Dynamic Data Authentication)
Unlike SDA, DDA relies on the card generating a dynamic signature using its own private key.
The terminal checks this signature with the verified ICC Public Key.
This means copying the static data alone is no longer enough.
CDA (Combined Dynamic Data Authentication)
CDA ties dynamic card authentication to the generation of the application cryptogram.
So in addition to cryptographic proof of the card's identity, certain critical transaction data is also bound to the signature.
| Aspect | SDA | DDA | CDA |
|---|---|---|---|
| Issuer certificate | Used | Used | Used |
| ICC certificate | Not required | Used | Used |
| Card's dynamic signature | No | Yes | Yes |
| Combined verification with transaction cryptogram | No | No | Yes |
| Protection against copying static data | Limited | Stronger | Stronger |
This comparison applies to the classic RSA-based EMV offline authentication model. EMV's newer ECC-based methods may use different key and certificate formats.
8. What happens if certificate verification fails?
A POS terminal can run into various errors while verifying certificates.
For example:
- The CA Public Key can't be found
- The issuer or ICC certificate has expired
- The certificate integrity check fails
- Expected certificate or key data is missing
- The dynamic signature can't be verified
- The certificate is found to be invalid via a supported revocation list
Situations like these affect the terminal's verification results.
However, it isn't correct to say that every transaction is immediately declined when offline authentication fails.
The terminal updates the Terminal Verification Results (TVR) according to the rules of the terminal, the card and the payment scheme.
Then, during the terminal and card risk management and action analysis stages, the transaction may be sent for online authorization, declined, or reach another appropriate outcome.
Offline data authentication is different from the authorization process, in which the issuer evaluates the transaction amount, card status and other risks online.
9. Where does the HSM fit in?
An HSM (Hardware Security Module) is an important security component in certificate and key management.
Secure cryptographic environments can be used in particular for protecting CA and issuer private keys, key generation and digital signing.
For example:
- The CA Private Key is used to sign the Issuer Public Key Certificate.
- The Issuer Private Key is used to sign the ICC Public Key Certificate.
- The ICC Private Key is used to create dynamic signatures on the card.
These private keys don't all have to live in the same HSM.
CA, issuer and card keys are managed in different security domains and through different lifecycle processes.
Also, the EMV offline authentication certificate chain is not the same thing as the symmetric key management used by the issuer to verify online transaction cryptograms (for example, the ARQC).
The two mechanisms can complement each other, but their purposes and the types of keys they use are different.
10. Why use a three-layer chain of trust?
Think about it this way:
A POS terminal may encounter millions of cards issued by different banks in different countries around the world.
Preloading every card's public key onto the terminal isn't practical.
Likewise, manually setting up a separate trust relationship on the terminal for every card of every bank wouldn't scale.
That's why a hierarchical trust model is used.
The terminal holds trusted CA Public Keys for the relevant payment application.
The CA certifies the issuer's public key.
The issuer, in turn, certifies the card's ICC public key.
As a result, starting from the CA Public Key it trusts from the outset, the terminal can perform a verification that extends all the way to the card's public key.
This architecture is one of the core cryptographic approaches that allows millions of cards to be verified on independent terminals.
Wrapping up
EMV card security is not just about encrypting the data on the card.
The trustworthiness of the data the card presents can also be verified through public key certificates and digital signatures.
In this model:
- The CA certifies the issuer's public key.
- The issuer certifies the card's ICC public key.
- The ICC can perform dynamic authentication using its own private key.
- The POS terminal verifies the certificate chain, starting from the trusted CA Public Key.
So, in the appropriate EMV offline authentication process, the terminal can cryptographically assess the trustworthiness of the static data the card presents and, where DDA/CDA is used, whether the card holds the corresponding private key.
The certificates created during card personalization form a direct link between the card's production stage and the security checks at the moment of payment.
Understanding CA, issuer and ICC certificates is an important step toward grasping the security architecture of EMV, data preparation, HSMs and card personalization systems.