EMV Next Gen Architecture Overview v1.0 201409160406534

EMV*
Next Generation
Next Generation Kernel System

Architecture Overview
Version 1.0
September 2014
EMV is a registered trademark in the U.S. and other countries and an unregistered trademark
elsewhere. The EMV trademark is owned by EMVCo.
2012-2014 EMVCo, LLC (EMVCo). All rights reserved. Any and all uses of the EMV Specifications (Materials) shall be
permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo found at
http://www.emvco.com/specifications.aspx.
EMV Next Generation Kernel System

Architecture Overview v1.0
2012-2014 EMVCo, LLC (EMVCo). All rights reserved. Any and all uses of these
Specifications are subject to the terms and conditions of the EMVCo Terms of Use agreement
available at www.emvco.com. These Specifications are provided AS IS without warranties of
any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions
contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE
AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS.
EMVCo makes no representations or warranties with respect to intellectual property rights of
any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to
determine whether any implementation of these Specifications may violate, infringe, or
otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other
intellectual property rights of third parties, and thus any person who implements any part of
these Specifications should consult an intellectual property attorney before any such
implementation.
Without limiting the foregoing, the Specifications may provide for the use of public key
encryption and other technology, which may be the subject matter of patents in several
countries. Any party seeking to implement these Specifications is solely responsible for
determining whether its activities require a license to any such technology, including for patents
on public key encryption technology. EMVCo shall not be liable under any theory for any partys
infringement of any intellectual property rights in connection with these Specifications.

Contents
Contents
1
Introduction ................................................................................................................... 6
1.1
Audience ................................................................................................................ 6
1.2
Document Organization .......................................................................................... 7
System Architecture ..................................................................................................... 8

2.1
Overview of Structure ............................................................................................. 8
2.2
Acceptance Device ............................................................................................... 11

2.2.1
2.2.2
2.3
Kernel Director ..................................................................................................... 15
2.4
Next Gen Kernel ................................................................................................... 16

2.4.1
2.4.2
2.4.3
2.4.4
2.4.4.1
2.4.4.2
2.4.4.3
2.4.4.4
2.4.4.5
2.4.4.6
2.4.4.7
2.5
3
POI System vs. Acceptance Device ....................................................... 12

Adaptation Layer .................................................................................... 14
Architecture Principles ........................................................................... 16

Selection Manager ................................................................................. 17
Transaction Manager ............................................................................. 17
Next Gen Kernel Services ...................................................................... 18
Cardholder Verification Manager ..................................................................... 19
Terminal Risk Manager .................................................................................... 19
Payment Additional Services Manager ............................................................ 19
Payment Related Data Manager ..................................................................... 20
Issuer Authorisation Manager .......................................................................... 20
Data Communication Manager ........................................................................ 20
Secure Card Channel Manager ....................................................................... 21
Next Gen Systems Environment (NGSE) ............................................................. 21
Next Gen Security ....................................................................................................... 23

3.1
Next Gen Kernel to Card Security......................................................................... 24

3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.2
Secure Channel ..................................................................................... 24

Protection Against Eavesdropping ......................................................... 25
Protection Against Shims ....................................................................... 25
Protection Against Wedges .................................................................... 25
Protection Against Relay Attacks ........................................................... 26
Offline Card Authentication .................................................................... 26
CVM Encipherment to the Card ............................................................. 26
Card to Issuer Security ......................................................................................... 27

3.2.1
3.2.2
Card Authentication and Transaction Data Integrity ............................... 27

Issuer Card Management Functions ...................................................... 27
3.3
POI System Security Considerations .................................................................... 28
3.4
Additional Considerations ..................................................................................... 29
September 2014
EMVCo Confidential
Page iii
Contents

Processing Sequence ................................................................................................. 30

4.1
Overall Processing Sequence .............................................................................. 30
4.2
Application Selection ............................................................................................ 32

4.2.1
4.2.2
4.3
5
Transaction Processing ........................................................................................ 34
Communication Layering ........................................................................................... 38

5.1
Communication Between Kernel and Card ........................................................... 38
5.2
Data Exchange Within the Kernel ......................................................................... 40
5.3
Data Exchange Between Kernel and Card ........................................................... 41

5.3.1
5.3.2
Requesting Data Objects via DIL ........................................................... 41

Requesting Data Objects via Queries .................................................... 42
Non-functional Requirements .................................................................................... 44

6.1
Performance Requirements .................................................................................. 44
6.2
POI System Peripherals and User Interface ......................................................... 44
6.3
Testing and Type Approval ................................................................................... 45

6.3.1
6.3.2
6.3.3
Next Gen Detection................................................................................ 32

Build Candidate List ............................................................................... 32
Card Testing and Type Approval Scope ................................................. 45

Terminal Testing and Type Approval Scope........................................... 45
Terminal Type Approval Process ........................................................... 46
Migration ...................................................................................................................... 47
7.1
Application Selection ............................................................................................ 48
7.2
Kernel Director ..................................................................................................... 52

7.2.1
Application Selection Considerations for Legacy Kernels ....................... 53
7.3
Data Objects......................................................................................................... 55
7.4
Cryptography ........................................................................................................ 55
7.5
Communication Protocol ...................................................................................... 56
7.6
Future Evolution ................................................................................................... 57
Annex A
References ...................................................................................................... 58
Annex B
Abbreviations and Terminology .................................................................... 59
Page iv
EMVCo Confidential
September 2014

Figures
Figures
Figure 2-1:
Figure 4-1:
Figure 4-2:
Figure 4-3:
Figure 5-1:
Figure 5-2:
Figure 5-3:
Figure 5-4:
Figure 7-1:
Figure 7-2:
EMV Next Gen Acceptance Device .................................................................... 9

CVM, TRM, PRD Managers and Kernel Status ................................................ 35
Issuer Authorisation Manager Status ............................................................... 36
Transaction Status ........................................................................................... 37
Next Gen Kernel Communication Layering ...................................................... 39
Next Gen Message Basic Format.................................................................. 41
Next Gen Data Exchange with DILs ................................................................. 42
Next Gen Data Exchange with Queries ............................................................ 43
Application Selection Overview ........................................................................ 50
Next Gen and Legacy Sharing the Protocol Layer............................................ 56
Tables
Table 2-1:
Table 2-2:
Table 5-1:
Table A-1:
Table B-1:
Functional Responsibilities of Acceptance Device ............................................. 13

Functional Responsibilities of Kernel Director ................................................... 15
Information Exchange Terminology ................................................................... 38
References ....................................................................................................... 58
Abbreviations and Terminology......................................................................... 59
September 2014
EMVCo Confidential
Page v
1 Introduction
1.1 Audience

Introduction
EMV Next Generation (Next Gen) establishes a common, robust technology platform to
support a variety of interfacescontact, contactless, mobile, etc.for both online and offline
processing, by:
Enhancing transaction information available to acquirers, networks, and issuers
Optimising transaction flows to improve throughput at the point of sale and the
cardholder experience
Future proofing EMV security by incorporating next generation public key

infrastructure and a secure channel between the card and acceptance device
Supporting multiple communication protocols, with the flexibility to add additional

protocols in the future
Integrating Type Approval processes for contact and contactless
Special attention is given to migration and global interoperability between existing Legacy
EMV products and EMV Next Gen products. It is expected that cards and acceptance
devices based on Legacy EMV specifications might remain in the field until 2030.
The coexistence of Legacy and Next Gen applications (on the cards side) and Legacy and
Next Gen Kernels (on the acceptance device side) facilitates the introduction of new features
in response to individual market needs, while providing a natural migration path. Individual
Payment Systems and markets will determine when Next Gen products become relevant for
their needs, and may begin migrations well before 2030.
To minimize deployment costs and disruption in the field and to avoid multiple overlapping
migrationsespecially those that would require changes to acceptance devices and Type
Approval testingEMV Next Gen leverages recent evolutions in smart card, acceptance
device, and network technology; incorporating into the Next Generation Kernel System
Specifications ([Next Gen]) all the enhancements foreseen to keep EMV relevant for the next
20+ years. EMV Next Gen is designed so that the overall payment functionality and the
cardholder experience should not be impacted by whether Next Gen or Legacy EMV
functionality is used for a particular transaction.
This document outlines the architecture for the Next Generation of EMV Kernels, discussing
the modular architecture, security considerations, application selection and transaction
processing, information exchange, and migration considerations.
1.1
Audience
This document is intended for those who need an overall understanding of Next Gen.
Page 6
EMVCo Confidential
September 2014

1.2
1 Introduction
1.2 Document Organization
Document Organization
This document includes the following chapters and annexes.

Chapter 1 contains general information to help the reader understand and use this
document.
Chapter 2, System Architecture, provides an overview of the system architecture and
discusses the main modules the Kernel Director, Selection Manager, and Transaction
Manager and available services, as well as the Next Gen Systems Environment
(NGSE) on the card.
Chapter 3, Next Gen Security, describes Next Gen Kernel to card security, card to
issuer security, and additional considerations.
Chapter 4, Processing Sequence, describes the processing sequence, including
application selection, transaction processing, and closedown.
Chapter 5, Communication Layering, discusses Next Gen communication, both within
the Kernel and between the Kernel and the card.
Chapter 6, Non-functional Requirements, discusses performance and requirements
for POI System peripherals, as well as testing and type approval.
Chapter 7, Migration, discusses some aspects of migration from Legacy to Next Gen.
Annex A, References, lists documents referenced in this book.
Annex B, Abbreviations and Terminology, defines abbreviations and terminology
used in this book.
September 2014
EMVCo Confidential
Page 7
2 System Architecture
2.1 Overview of Structure

System Architecture
This document describes the EMV Next Generation (Next Gen) system architecture using a
logical representation, and does not presume any particular software architecture or physical
implementation.
2.1
Overview of Structure
A typical EMV Acceptance Device comprises the following components and functionality:
Core EMV Functionality, previously known as Level 2 Handles all dialogue with the
card and prepares the data required for network messaging. Core EMV Functionality
is (and will continue to be) evaluated for conformance by the EMVCo Type Approval
testing programme.
Card communication, previously known as Level 1 Provides application

independent lower level communication to contact and contactless cards. The
communication protocols are (and will continue to be) evaluated for hardware and
protocol conformance by the EMVCo Type Approval testing programme.
Point Of Interaction (POI) System This embraces all the other features and
functions of an Acceptance Device. The POI System typically supports cardholder
and merchant displays, data entry key pads, PIN entry devices, receipt printing,
signature capture, and network communication services. EMVCo has functional and
security requirements for some elements of the POI System, which are evaluated by
EMVCo or another body (e.g. PCI SSC). The POI System may also contain an
Adaptation Layer to facilitate integration with the Core EMV Functionality; this layer
and its functionality are described in section 2.2.2.
The structure of the Next Gen Acceptance Device can be described in terms of the
components illustrated in Figure 2-1.
Page 8
EMVCo Confidential
September 2014

Figure 2-1: EMV Next Gen Acceptance Device
Acceptance Device In the context of EMV Next Gen, includes:
POI System
Core EMV Functionality:

o
During the migration period:
Legacy Kernels for contact and contactless as appropriate
Kernel Director
Next Generation Kernel
Card communication:
o
Communication Abstraction Layer
Protocol Layer protocols
September 2014
EMVCo Confidential
Page 9

Point of Interaction (POI) System In the context of EMV Next Gen, the POI System is
considered to host the user interfaces for the cardholder and merchant, Payment System
network connectivity, peripheral devices such as PIN pads and receipt printers, and the
Adaptation Layer.
Adaptation Layer A component of the POI System that translates requests, responses,
and data objects between the formats used by the POI System and those used by the Core
EMV Functionality.
Kernel Director Directs the appropriate KernelNext Gen, Contact EMV, or Contactless
EMVto run the selected card application.
Legacy Kernels If directed by the Kernel Director, a Legacy Kernel delivers the functional
dialogue with the card, performs security processing, and provides data for transaction
messages.
Next Generation Kernel If directed by the Kernel Director during migrationand in all
cases after migrationdelivers the functional dialogue with the card, performs security
processing, and provides data for transaction messages. Can be considered as a software
module with sub-modules and library functions.
Communication Abstraction Layer (CAL) Provides connection, link, and session
management, as well as binding to the Protocol Layer protocols. This architecture allows for
the possibility to add other communication protocols in the future.
Protocol Layer Provides lower level communication to contact and/or contactless cards
and/or mobile phones.
Page 10
EMVCo Confidential
September 2014

2.2
2.2 Acceptance Device
Acceptance Device
The generic term acceptance device describes a device deployed at a physical merchant
location that:
Allows transactions to be initiated
Communicates with cards
Provides progress and disposition information to both the merchant and cardholder
Allows entry of some forms of Cardholder Verification Data
Communicates with a network for authorisation and/or clearing purposes
This generic description embraces a wide range of device classes that accept cards for
payment and payment related purposes. These include counter top acceptance devices,
electronic till systems, ATMs, vending machines, and transport gates. Within each class of
device, a wide variation of physical implementations can be expected, with perhaps the most
significant differences being the provision for the presentation of cards and Cardholder
Verification Data entry. As examples, an electronic till may have separate readers for
contactless and contact cards and an online encrypting PIN pad, while a counter top
acceptance device may be a fully integrated device that supports all card interfaces and
Cardholder Verification Data entry in a single unit.
In addition, the software and functionality may be distributed in a variety of ways, from a
single integrated module to multiple dumb card readers connected as remotes to a
multi-tasking host.
Devices also vary in terms of the types of transaction they support, including purchase,
purchase with cashback, refund, reversal, and cash withdrawal. A full list of the transaction
types EMV Next Gen is designed to fulfil will be provided in the Data Dictionary.
Some devices may also support other payment related services; for example, ATMs may
have menus for balance enquiry and PIN change, or electronic till systems may support
store loyalty programmes.
The Next Gen Architecture seeks to encompass all acceptance environments, treating
acceptance devices as generic entities, although in practice there will be a variety of
implementation options; for example, not all devices will support all interfaces, and some
devices may operate exclusively online or exclusively offline.
September 2014
EMVCo Confidential
Page 11
2.2.1

POI System vs. Acceptance Device
Although acceptance device and POI system may be interchangeable in general usage,
within the context of EMV Next Gen, they have distinct meanings.
The POI System is a subset of the Acceptance Device, responsible for user interfaces for
the cardholder and merchant, Payment System network connectivity, and peripheral devices
such as PIN pads and receipt printers.
Table 2-1 lists the functional responsibilities of the Acceptance Device, including those of the
POI System.
Page 12
EMVCo Confidential
September 2014

Table 2-1: Functional Responsibilities of Acceptance Device

Acceptance Device Function
POI
System
Initiate new transactions, including data entry (amount) by

the merchant
Choose interface: contact, contactless, etc.
Support Next Generation Kernel
Core EMV
Functionality
X
X
Provide transaction and configuration data in Next Gen data

format
Support contact and contactless Legacy Kernels (if present)
Display information to the merchant and the cardholder
Manage entry of Cardholder Verification Data for offline PIN,

online PIN, Match-On-Card biometrics, signature, etc.
Process offline dispositions (approvals and declines)

Send Authorisation Requests and receive Authorisation
Responses
X
X
Process online dispositions (approvals, declines, and

referrals)
Forward online response data to the card
Print receipts
Send clearing records
Prevent overlapping transactions
Prevent unintended contactless transactions
Manage other aspects of transaction processing, including

timeouts and cancellations
This is not an exhaustive list and some functionality may be optional.
September 2014
EMVCo Confidential
Page 13
2.2.2

Adaptation Layer
Because the interface between POI Systems and EMV Kernels is not standardized,
transaction messages and data produced by POI Systems are not necessarily in Next Gen
format. For these POI Systems, the Adaptation Layer is a component of the POI System that
supports integration with the Core EMV Functionality.
The Adaptation Layer needs to be able to:
Relay requests between the POI System and the Core EMV Functionality.
When the POI System has completed a request, translate its response into the
equivalent messages for the Core EMV Functionality.
Handle any requests from the Core EMV Functionality that the POI System cannot
fulfil (for example, send revised transaction details after the application has been
selected).
When the Core EMV Functionality has completed a request, translate its response
into the equivalent messages for the POI System.
Transform, input data that the POI System provides to the Core EMV Functionality
from the format used by the POI System into the Next Gen data format.
Transform data objects that the Core EMV Functionality provides to the POI System
from Next Gen data format to a format that the POI System can interpret.
POI Systems that can directly process Next Gen messages and data format may not require
an Adaptation Layer.
Page 14
EMVCo Confidential
September 2014

2.3
2.3 Kernel Director
Kernel Director
When the POI System starts a transaction, the Kernel Director initiates the Next Gen Kernel
to perform Application Selection. Based on the outcome of Application Selection, the Kernel
Director activates either a Legacy Kernel or a Next Gen Kernel to process the transaction.
The Next Gen Systems Environment (NGSE) is a card application that provides to the Next
Gen Kernel dynamic information regarding the payment applications available on the card. 1
Table 2-2: Functional Responsibilities of Kernel Director
NGSE on
Card?
Yes
If...
Selected
application is
Next Gen
Selected
application is
Legacy
...then the Kernel Director:

Initiates a Next Gen transaction.
Routes subsequent messages (including Authorisation
Request and Authorisation Response) between the Next
Gen Kernel and the POI System.
Initiates as appropriate either the Legacy contact Kernel
or Entry Point, providing information from the NGSE that
is equivalent to that from the PSE entry (if any) or PPSE
entry, so that application selection is not performed twice
(by the legacy functions).
Request and Authorisation Response) between the
Legacy contact Kernel or Entry Point and the POI System.
No
Card is on
contact
interface
Initiates the Legacy contact Kernel to do its own

application selection and transaction processing.
Card is on
contactless
interface
Initiates the Legacy contactless Entry Point to do its own

application selection and select the appropriate
contactless Kernel.

Request and Authorisation Response) between the
Legacy contact Kernel and the POI System.

Request and Authorisation Response) between Entry
Point and the POI System.
For more details, see section 2.5.
September 2014
EMVCo Confidential
Page 15
2.4 Next Gen Kernel
2.4
2.4.1

Next Gen Kernel

Architecture Principles
The Next Gen Kernel is described as a multi-module system, implementing an event driven
architecture. Notable characteristics defined for the system are the following:
Each module is self-contained and conceived as a single process.
A module produces and consumes events, and processes one event at a time.
Events received while processing an event are placed in an event queue

(first-in-first-out).
Events may contain data as parameters.
The Kernel adheres to these principles and is comprised of the following modules:
A Selection Manager that performs the initial selection process and determines
whether the transaction will use Next Gen or Legacy functionality.
A Transaction Manager that controls the high level sequencing of transaction

processing.
A set of services, each responsible for a self-contained function or functions, that

may interact with other services or utilities. An example is the Terminal Risk
Manager. Services are partitioned for convenience and are not prescriptive (in terms
of design and implementation). Services may be invoked at multiple steps during
processing.
The following sections provide a high-level description of the functionality of these elements.
Page 16
EMVCo Confidential
September 2014

2.4.2
2.4 Next Gen Kernel
Selection Manager
If the card has an NGSE, the Selection Manager determines whether the card has an
appropriate application to perform the payment transaction. More specifically:
The Selection Manager determines whether the card has an NGSE (see section 2.5).
2.4.3
If the card has an NGSE, then the Selection Manager builds the candidate list for the
Next Gen payment application. This processing results in one of the following:
o
Selection of the Next Gen application
Indication to the Kernel Director that the application to be used requires use of a
Legacy Kernel
Indication that there is no available application
If the card does not have an NGSE, then the Selection Manager indicates to the
Kernel Director that the card is not Next Gen capable. The Kernel Director redirects
the transaction to the Legacy selection process for contact or contactless.
Transaction Manager
The Transaction Manager oversees the Next Gen Application Layer session, beginning once
the payment application has been selected and continuing through to the transaction
disposition for offline, data preparation for online, and processing of information returned in
the Authorisation Response.
The Transaction Manager communicates with various components of the POI System, for
example to prepare messages and request online authorisation or clearing, and to collect
any returning issuer management information.
To determine the transaction disposition, the Transaction Manager combines the results of
processing by several Next Gen Kernel services (all described in section 2.4.4): Cardholder
Verification Manager, Terminal Risk Manager, Payment Related Data Manager, and Issuer
Authorisation Manager.
Messages for online authorisation and clearing consist of the data object set defined by
EMVCo. The data object sets are defined and consistent, although the network message
formats vary according to the acquiring environment, such as national data standards.
Issuer updates for the card returned in response to an online authorisation are forwarded to
the card as received.
September 2014
EMVCo Confidential
Page 17
2.4 Next Gen Kernel
2.4.4

Next Gen Kernel Services
The following services are defined:

2.4.4.1
Cardholder Verification Manager ........................................... 19
2.4.4.2
Terminal Risk Manager ......................................................... 19
2.4.4.3
Payment Additional Services Manager.................................. 19
2.4.4.4
Payment Related Data Manager ........................................... 20
2.4.4.5
Issuer Authorisation Manager ............................................... 20
2.4.4.6
Data Communication Manager.............................................. 20
2.4.4.7
Secure Card Channel Manager............................................. 21
Page 18
EMVCo Confidential
September 2014

2.4.4.1
2.4 Next Gen Kernel
Cardholder Verification Manager
The Cardholder Verification Manager (CV Manager) provides services related to cardholder
verification. Cardholder Verification Methods (CVMs) fall into three main categories:
Prior and external to the transaction session e.g. confirmation code entered on a
mobile phone
During the transaction session e.g. offline PIN
Outside of the transaction session signature
The CVMs to be applied for the transaction depend on:
The CVM(s) supported by the Kernel for the transaction
The CVM(s) requested by the card
The CV Manager communicates with the POI System to capture the Cardholder Verification
Data; e.g. offline PIN, Match-On-Card biometrics, or signature.
After cardholder verification is performed, the CV Manager provides the Transaction
Manager with its position on the transaction:
Either Offline or Online Authorisation Allowed
Go Online
Approve
Decline
2.4.4.2
Terminal Risk Manager
The Terminal Risk Manager (TR Manager) performs a series of risk checks and provides the
Transaction Manager with its position on the transaction:
Offline Authorisation Allowed
Go Online
Approve
Decline
2.4.4.3
Payment Additional Services Manager
The Payment Additional Services Manager (PAS Manager) provides additional payment
services for EMV transactions. Such additional services include cashback, card proposed
amount, and currency conversion. The PAS Manager reports the results of its processing to
the Selection Manager, and the transaction continues with or without additional services.
That is, PAS Manager processing never causes a transaction to be aborted or declined.
September 2014
EMVCo Confidential
Page 19
2.4 Next Gen Kernel
2.4.4.4

Payment Related Data Manager
The Payment Related Data Manager (PRD Manager) provides services related to the
transfer of additional data between the card and the POI System. For example, this could be
transit, loyalty, or coupon data. The PRD Manager provides the Transaction Manager with its
position on the transaction:
Offline Authorisation Allowed
Go Online
Failed
Complete
The PRD Manager may say that a transaction failed if, for example, an attempted transit
purchase will fail because the card is unable to load the ticket.
2.4.4.5
Issuer Authorisation Manager
The Issuer Authorisation Manager acts as the proxy for the issuer to perform data analysis
for transaction authorisation purposes, especially when the card is no longer present to
perform these tasks (e.g. after a contactless single presentment transaction that requires
online authorisation). Specific behaviour for this service is configurable. The Issuer
Authorisation Manager provides the Transaction Manager with its position on the
transaction:
Go Online
Approve
Decline
2.4.4.6
Data Communication Manager
The Data Communication Manager (DCM) performs services relating to data exchange
between the Next Gen Kernel (Application Layer) and the card. The DCM is also responsible
for ensuring that data exchange adheres to the information exchange principles discussed in
section 5.3.
Page 20
EMVCo Confidential
September 2014

2.4.4.7
2.5 Next Gen Systems Environment (NGSE)
Secure Card Channel Manager
The Secure Card Channel Manager (SCC Manager) performs services related to data
protection and card authentication (see Chapter 3 for further details).
Session keys are established through an approach using Elliptic Curve Cryptography
(ECC) as the public key algorithm and with the cards (ECC) public key certificate
chain verified by the SCC Manager. There is no corresponding acceptance device
certificate chain.
The SCC Manager uses the session keys to protect the data exchanges between the
card and the Next Gen Kernel against a variety of attacks. The protection mechanism
authenticates the card and provides integrity for the data exchange, including
cardholder verification data encryption.
The approach affords some privacy to the cardholder in that an attacker who
passively eavesdrops on communications will find it difficult to identify a particular
card.
The secure channel is also used to implement a distance bounding protocol to

provide protection against relay attacks.
The SCC Manager provides the following information to help the other modules determine
their position on the transaction:
Secure channel established
Relay attack detected
Secure channel validated
2.5
Next Gen Systems Environment (NGSE)
The Next Gen Systems Environment (NGSE) is a card application defined by EMVCo,
similar to the Payment Systems Environment (PSE) described in Book 1 of [EMV CT] and
the Proximity Payment Systems Environment (PPSE) described in Book B of [EMV CL].
Similarly to PPSE, NGSE is mandatory on an EMV Next Gen capable card.
In essence the NGSE provides information in the form of a structured list of data and,
similarly to contactless mobile payment (see [AAUI]), the NGSE provides dynamic
information, rather than a static data structure fixed at personalization. The information the
NGSE provides to the Selection Manager varies depending on the information sent to the
card, the transaction characteristics, and the terminal capabilities.
By adapting its response to the transaction context, the NGSE has the objective of providing
to the merchantand if cardholder choice is supported, to the cardholdera list of one or
more card applications adapted to that precise environment in order to successfully conduct
a payment transaction.
September 2014
EMVCo Confidential
Page 21
2.5 Next Gen Systems Environment (NGSE)

The level of complexity of NGSE processing depends on the issuers application selection
criteria. It can range from a simple static response (e.g. a single or few applications, one
Terminal Risk Management (TRM) and one CVM requirement, no additional services) to
sophisticated processing based on multiple criteria (e.g. card interface, amount, transaction
type, terminal country code, etc.). The Next Gen architecture is designed to address a
multitude of card and application implementations, from the simplest to the more
sophisticated.
Furthermore, similarly to contactless mobile payment, a dynamic NGSE could be kept aware
in real-time of a status change by an on-card payment application such as:
activated/deactivated (see [AAUI]) or blocked/unblocked.
The Next Gen architecture supports a combination of Legacy and Next Gen applications on
the same card and on the same acceptance device. To enable the Next Gen application
selection mechanism to also select Legacy applications when appropriate, an NGSE entry
must exist for each Next Gen payment application and for each Legacy-only payment
application present on the card. It is recommended that the NGSE entry for each Legacy
payment application includes the minimum information (such as CVM capabilities) needed
from the card to optimize the eventual choice of a Legacy application by leveraging the Next
Gen application selection mechanism.
Note: While the actual on-card implementation of the NGSE (and its eventual interfaces
with on-card payment applications) is out of scope of EMVCo, EMVCo will provide testing
and type approval services for the NGSE interface to the Next Gen Kernel.
Page 22
EMVCo Confidential
September 2014

3 Next Gen Security
Next Gen Security
The Next Gen crypto is designed to deliver the following security services for both contact
and contactless payment transactions. Whilst some have more utility for contactless, the
same security services are delivered irrespective of interface type.
Next Gen Kernel to Card Security

o
Protection against eavesdropping
Protection against shims
Protection against wedges
Protection against relay attacks
Offline card authentication
CVM encipherment to the card
Card to Issuer Security

o
Online (issuer) card authentication and transaction data integrity
Issuer card management functions
Online response authentication
POI System Security

o
Software integrity
Transaction data integrity
Key distribution operations
This chapter discusses the three categories of security, as well as additional security
considerations.
September 2014
EMVCo Confidential
Page 23
3 Next Gen Security

3.1 Next Gen Kernel to Card Security
3.1

Next Gen Kernel to Card Security
The first group of services listed on page 23 relate to the immediate local environment
between the Next Gen Kernel and the card. They are all delivered through the primary
mechanism of a secure channel.
3.1.1
Secure Channel
The secure channel is established using an elliptic curve Diffie-Hellman key establishment
protocol with blinding applied by the card. The card is required to have a unique
private/public key pair with a three tier certificate chain (Card Issuer Payment System)
for validation of the card public key. Establishment of the channel consists of four steps:
1. The card generates a random blinding factor and multiplies its public key by this
value to produce the card component of the exchange, which is sent to the Next Gen
Kernel.
2. The Next Gen Kernel generates a random key pair, retaining the private part and
sending the public part to the card as the Next Gen Kernel component of the
exchange.
3. Each party (Next Gen Kernel and card) uses its private key and the component
supplied by the other party, to calculate the Diffie-Hellman ephemeral value. Due to
the structure of the protocol, both sides will arrive at the same value.
4. Each party uses a common protocol to extract two symmetric keys from the
ephemeral value. One key is designated for use in the Next Gen Kernel to card
direction and the other for the opposite direction.
Once the secure channel is established, data transmitted from the Next Gen Kernel is
encrypted and MACed using an authenticated encryption algorithm, and is validated and
decrypted by the card. The same happens in the opposite direction for data between the
card and the Next Gen Kernel.
Page 24
EMVCo Confidential
September 2014

3.1.2
3 Next Gen Security

Protection Against Eavesdropping
The nature of the Diffie-Hellman protocol means that an external party that obtains one or
both of the exchanged components cannot calculate the secure channel keys without
knowledge of one of the private keys. The component sent from the Next Gen Kernel will
appear to an eavesdropper as if it were a random number and the blinding factor in the card
causes the card public key component also to appear to an eavesdropper as if it were a
random number.
Once established, the secure channel encryption prevents an eavesdropper obtaining
transaction data.
Privacy concerns relating to tracking fixed data in the card are addressed because the card
public key is masked and the PAN and certificate chain are only provided once the secure
channel is established, when they will be encrypted.
3.1.3
Protection Against Shims
Shims are devices fraudulently added to the Kernel to card communication channel of an
Acceptance Device. Passive shims can only record data and being a form of eavesdropping
are defeated as described above.
Active shims that seek to manipulate transaction data cannot simply modify data that is
protected by the secure channel. Thus the active shim would essentially need to act as a
man-in-the-middle and establish two secure channels one to the Next Gen Kernel and one
to the card. However, the key that the shim would need to use towards the Next Gen Kernel
to impersonate the card will not validate under the card certificate chain and thus the Next
Gen Kernel will be able to detect a problem.
Shims inserted in an Acceptance Device purely to gather card data are not prevented by the
secure channel, however this makes them no different from a simple fake acceptance device
in that the data gathered from the card cannot be used in a replay attack.
3.1.4
Protection Against Wedges
Wedges are fraudulent devices introduced by a fraudster between the card (typically stolen)
and the Acceptance Device. For example the card could be wired to an external computer,
or a more sophisticated approach might be to add a chip into the body of the card itself. For
a stolen mobile phone it might be possible to download an app that acts as a wedge device
for the payment application in the secure element. Wedges can be assumed to be active
with the most likely intent being to use a stolen card without knowing the PIN. As above, an
active wedge will be detected because the secure channel will not validate since the wedge
will not know the card key.
September 2014
EMVCo Confidential
Page 25
3 Next Gen Security

3.1.5

Protection Against Relay Attacks
The EMV Next Gen architecture can provide protection against simple relay attacks by
means of the exchange of two random values, with the time taken by the exchange
measured by the Next Gen Kernel. This is done before the secure channel is established
to deliver a short exchange time with a small possible variation. Once the secure channel
has been established, the card sends back to the Kernel the random value it originally used,
the random value it saw from the Kernel, and the time it took to do the exchange.
If the Kernel finds there is a mismatch between the random values it saw in the initial
exchange and the values the card reports that it saw, or if the difference between the times
measured by the terminal and reported by the card is significant, then the Next Gen Kernel
has detected that a relay attack may be occurring.
Whilst the relay chain could act as a shim or wedge and manipulate the values as a man-inthe-middle, this would again be detected as described above.
3.1.6
Offline Card Authentication
Offline card authentication is achieved by verifying that the card established the secure
channel using a genuine public/private key pair. This is done by validating the card public
key via the certificate chain personalised on the card by the issuer. The Next Gen Kernel will
check that the card public key is consistent with the blinded version using the value of the
blinding factor provided by the card via the secure channel.
The validation might not occur until later in the transaction particularly for contactless when
the card may have left the field. Therefore, Next Gen Kernels will complete a transaction with
data that is genuine in the context of the secure channel this is taken on trust until the card
key is validated. Once the card key has been validated, the Next Gen Kernel has enough
assurance for an offline approval, if this is the intended transaction disposition.
3.1.7
CVM Encipherment to the Card
The secure channel can be considered secure enough for protecting a CVM (e.g. PIN) being
sent to the card. However, to prevent a wedge or shim obtaining the data as a man-in-themiddle, the CVM data should not be sent by the Next Gen Kernel until trust in the secure
channel is established through validation of the certificate chain. The card may verify the
CVM (e.g. offline PIN verification) or encrypt it to send to the issuer.
Page 26
EMVCo Confidential
September 2014

3.2
3 Next Gen Security

3.2 Card to Issuer Security
Card to Issuer Security
The second group of services listed on page 23 relate to the Authorisation Request and
Authorisation Response of an online transaction.
3.2.1
Card Authentication and Transaction Data Integrity
Online card authentication is delivered through a cryptogram using a usually symmetric

algorithm and a card secret key, more or less the same as with Legacy EMV. The
cryptogram also allows the issuer to validate the integrity of critical transaction data. The
choice of algorithm for online card authentication is left to the Payment System or issuer.
3.2.2
Issuer Card Management Functions
Issuer card management is via a message returned with the Authorisation Response by the
issuer. The whole message is delivered to the card by the Next Gen Kernel and the
processing expected of the card is according to the issuers specification. This message is
likely to be cryptographically protected and by issuer choice may include issuer
authentication equivalent to todays ARPC.
If the card is still present and has indicated to the Next Gen Kernel it expects issuer data,
any issuer card management, e.g. issuer updates, that might have been included in the
online response are forwarded to the card payment application.
Some card devices (e.g. mobile phones) may be managed by out of band channels, which is
out of scope for EMVCo.
September 2014
EMVCo Confidential
Page 27
3 Next Gen Security

3.3 POI System Security Considerations
3.3

POI System Security Considerations
EMV POI Systems are not required to retain secret or private keys as part of the EMV
protocols and therefore do not require an evaluated secure element. However the following
security principles should be considered:
Integrity of Payment System public keys
Integrity of configuration data
Integrity of software code
Authentication of public key load
Authentication of configuration updates
Authentication of software updates
Separation and control of code, configuration data, and transaction data
Deletion of transient data
Quality of any unpredictable numbers generated
Tamper resilient and tamper evident technology
Integrity and protection of transaction data
Software as well as data initialized in the POI System, including cryptographic keys, should
not be erased or altered for the period of time the software and data are valid. POI Systems
are expected to have memory protection mechanisms in place to satisfy this need.
EMV Next Gen will also take into account the results of existing collaboration efforts
undertaken by EMVCo and PCI Security Standards Council to optimize terminal evaluation
and approval processes.
Page 28
EMVCo Confidential
September 2014

3.4
3 Next Gen Security

3.4 Additional Considerations
Additional Considerations
The mandated presence of a secure channel is still under discussion at EMVCo.
New CVM methods may be supported, e.g. biometrics. The secure channel will
protect such CVM values as previously described.
A Suspend and Resume feature allows a transaction to be suspended and resumed

later (e.g. two taps for contactless). The secure channel is resumed as it was at the
point it was suspended without re-initiating the secure channel; that is, all
subsequent data exchanged between the Next Gen Kernel and the card is encrypted
and MACed using the previously established session keys.
The secure channel does not protect against e-pickpocketing.
The secure channel does not protect against PIN phishing attacks. In these a
fraudsters card reader or shim will attempt dummy transactions and try a small
number of commonly used PIN numbers (typically two, to avoid blocking the PIN).
Statistically, enough attempts will obtain a positive response and the card becomes a
target for theft or misuse.
September 2014
EMVCo Confidential
Page 29
4 Processing Sequence
4.1 Overall Processing Sequence

Processing Sequence
This chapter provides a high level description of the processing for a Next Gen transaction,
with emphasis on how the modules interact to reach a final transaction outcome.
4.1
Overall Processing Sequence
A transaction begins with the POI System requesting the Kernel Director to start a
transaction. The Kernel Director will attempt either a Next Gen transaction or a Legacy
transaction, as appropriate.
The overall transaction can be broken into two major steps:
Application selection to choose the application and determine whether the

transaction will be conducted as Next Gen or Legacy
Next Gen transaction processing if the chosen application is a Next Gen application
When the application chosen to process the transaction is a Next Gen application on both
the card and the POI System, then the overall Next Gen transaction flow consists of the
following blocks:
Transaction pre-processing and detection of a Next Gen Card
Building of the candidate list and cardholder choice of application and additional
services
Initial assessment of the transaction, including the possible establishment of a secure

channel that protects the integrity and authenticity of the data
CVM processing Fine tuning the initial assessment of the transaction during
pre-processing to determine whether Cardholder Verification must be performed and
with what method(s), such as online PIN, offline PIN, signature, etc.
TRM processing Fine tuning the initial assessment of terminal risk during
pre-processing, including interpreting the cards response and determining whether
the transaction can be authorised offline, should be authorised online, or should be
declined offline.
PRD processing Using the card-supplied information to provide additional PRD

services and to determine whether additional PR data must be sent to the card
and/or requested from the card.
Issuer Authorisation Processing In order to allow for a cardholder experience

similar to the existing contactless transaction flow, the card may choose to delegate
authority to approve or decline an Online Only transaction.
Page 30
EMVCo Confidential
September 2014

4.1 Overall Processing Sequence
Authorisation Using information from the CV Manager, the TR Manager, the card
payment application or the Issuer Authorisation Manager, and optionally the PRD
Manager to determine the type of authorisation processing to perform, and
performing the authorisation.
Closedown Ending transaction processing and ensuring appropriate removal of

sensitive data.
September 2014
EMVCo Confidential
Page 31
4.2 Application Selection
4.2
4.2.1

Application Selection
Next Gen Detection
After the POI System kicks off the transaction by triggering the Kernel Director, the Kernel
Director calls upon the Selection Manager to check:
(1) Which applications on the POI SystemNext Gen and/or Legacy, over a contact
and/or contactless interfaceare eligible for the given transaction circumstances, based
on the POI Systems Cardholder Verification and Terminal Risk Management
requirements for each payment application available on the acceptance device.
(2) Whether the card is Next Gen capable
For (1), the Selection Manager calls upon the CV Manager, TR Manager, PAS Manager, and
PRD Manager to compile an initial list of available payment applications and associated
requirements. This pre-processing determines:
The list of payment applications that meet the CVM and TRM criteria for the
transaction (e.g. the transaction amount is over the floor limit, so the merchant
requires an application that can go online, and also requires a CVM of signature or
offline PIN)
The list of additional PAS and/or PRD services that could be offered to the
cardholder as choices
For (2), once communication is set up with the card over either the contact or contactless
interface, the Selection Manager requests to open the NGSE application on the card. 2 If the
card accepts the request, then the card is Next Gen capable. If the card is not a Next Gen
card, then Next Gen processing stops and the Kernel Director reverts to Legacy processing.
4.2.2
Build Candidate List
The combined lists of initial CVM and TRM requirements of the Acceptance Device
determine the initial terminal capabilities relevant to the current transaction. Those initial
terminal capabilities, the possible additional PAS and PRD services, together with the
transaction detailsAmount, Transaction Type, etc.are sent to the NGSE application on
the card.
For ISO 7816-4 protocols, the request is a SELECT NGSE command.
Page 32
EMVCo Confidential
September 2014

The NGSE application on the card performs its own internal processing to determine which
applications could be available for this transaction based on the transaction details (including
the current contact or contactless interface) and the initial capabilities of the acceptance
device for such a transaction. The NGSE application responds with a list of payment
applications available on the card, associated CVM and TRM requirements from the cards
point of view, and associated PAS and PRD services to be presented to the cardholder.
The Selection Manager builds the candidate list of payment applications that match both the
cards and acceptance devices CVM and TRM requirements. The Selection Manager also
builds the candidate list of additional PAS and PRD services that are supported by both the
card and acceptance device.
Next Gen introduces the concept of a group of applications, as determined by the issuer,
within which the merchant may specify their preferred application. This facilitates, for
example, using a domestic payment system application within the cardholder's domestic
market, and a global payment system application outside of the cardholder's domestic
market. If the list of eligible payment applications has multiple applications that belong to the
same group, the Selection Manager chooses which application within the group will be used
in the candidate list based on the merchants preference. Only one payment application from
each group is offered to the cardholder.
When cardholder choice is supported, the Selection Manager will instruct the POI System to
ask for and obtain the cardholders choice of both the payment application and additional
services. When additional PAS and/or PRD services are chosen, the POI System is
responsible for updating the initial transaction details such as amount (e.g. when a coupon
or loyalty points are redeemed), or currency code (e.g. for currency conversion by the
acceptance device) and finalising them prior to the actual processing of the transaction.
Once the final payment application has been selected, the Selection Manager passes this
information to the Kernel Director. If a Legacy payment application is selected, then Next
Gen processing stops and the Kernel Director reverts to the appropriate Legacy Kernel; see
further details on migration in section 7.1.
September 2014
EMVCo Confidential
Page 33
4.3 Transaction Processing
4.3

Transaction Processing
The Transaction Manager and Data Communication Manager call upon the CV Manager, the
TR Manager, the PRD Manager, and the card as often as necessary during transaction
processing, until all necessary data has been exchanged, all necessary processing is
complete, and a final transaction outcome approved or declined has been reached.
The Data Communication Manager exchanges information with the card and makes the
card-supplied information available to the Next Gen Kernel modules.
The TR Manager uses the card-supplied information to establish the applicable

terminal risk management processing requirements and determine whether the
transaction can be authorised offline, should be authorised online, or should be
declined offline.
The CV Manager uses the card-supplied information to establish the applicable

cardholder verification processing requirements and determine whether Cardholder
Verification must be performed and with what method(s), such as online PIN, offline
PIN, signature, etc.
The PRD Manager uses the card-supplied information to provide additional PRD
services and to determine whether additional PR data must be sent to the card
and/or requested from the card.
The Issuer Authorisation Manager uses the card-supplied information to determine

whether the card may be removed or not from the Acceptance Device while the POI
System is going online and processes the issuer online response.
The CV Manager, TR Manager, PRD Manager. and Issuer Authorisation Manager return
their respective findings to the Data Communication Manager, which consolidates their
views and compiles them with the transaction details into messages for the card including
amount, currency, transaction type, CVM requirements, TRM requirements, PR data,
identifiers of additional data requested from the card, etc.
The card payment application:
Processes the information received from the Data Communication Manager to

determine its own CVM and TRM requirements as well as verify their fulfilment.
Handles the additional PR data received.
In its response to the Data Communication Manager, provides the information

requested by the CV Manager, TR Manager, PRD Manager, and/or Issuer
Authorisation Manager and eventually indicates its decision on the transaction
outcome.
Page 34
EMVCo Confidential
September 2014

This processing loop, including the exchange of information with the card payment
application, is repeated until all information is exchanged with the card; the CV Manager, TR
Manager, PRD Manager, and Issuer Authorisation Manager modules have completed their
processing; and the final transaction outcome approved or declined is reached by the
Transaction Manager.
As illustrated in Figure 4-1, the CV Manager, TR Manager, and PRD Manager begin with a
status of Undecided, may pass through an initial status of Online Only, Offline Only, or Either
Online or Offline Is Okay, and end with a status of Approve or Decline. (For the PRD
Manager, Failed replaces Decline and Complete replaces Approve). The status Abort
reflects an exception (e.g. fatal error) in the module processing. The Kernel Status is a
combination of the statuses of these three modules.
Note: No status decision may be reverted; e.g. if the CV Manager has reported a status of
Online Only, it cannot subsequently report a status of Undecided.
Figure 4-1: CVM, TRM, PRD Managers and Kernel Status
September 2014
EMVCo Confidential
Page 35

As illustrated in Figure 4-2, the Issuer Authorisation Manager begins with a status of
Undecided, may pass through an initial status of Online Only, and ends with a status of
Approve or Decline the status Abort reflecting an exception (e.g. fatal error) in the
communication with the card and/or card processing. The Issuer Authorisation Manager
Status is a combination of the Card Payment Application Status and the Issuer Authorisation
Status received if the transaction has gone online.
Figure 4-2: Issuer Authorisation Manager Status
Page 36
EMVCo Confidential
September 2014

The Transaction Status is a combination of the Kernel Status and Issuer Authorisation
Manager Status. It is managed by the Transaction Manager to determine the final
transaction outcome: Approved or Declined. As illustrated in Figure 4-3, the Transaction
Status begins with a status of Undecided, may pass through an initial status of Online Only
or Offline Only before reaching the final outcome of Approve or Decline the status Abort
reflects an exception (e.g. fatal error) in the transaction processing.
Figure 4-3: Transaction Status
September 2014
EMVCo Confidential
Page 37
5 Communication Layering
5.1 Communication Between Kernel and Card

Communication Layering
The Next Gen Kernel is separated into the following logical layers:
Application Layer
Secure Channel Layer
Communication Abstraction Layer (CAL)
Protocol Layer
Having the CAL between the Application Layer and the Protocol Layer and between the
Secure Channel Layer and the Protocol Layer allows the Application Layer and Secure
Channel Layer to be communication protocol agnostic. Thus, although [Next Gen] v1.0
supports only Contact and Contactless, additional protocols can be added with minimal
change to the Application Layer.
5.1
Communication Between Kernel and Card
The layered approach of the Next Gen Architecture distinguishes between information
exchanged at various levels using the following terminology:
Table 5-1: Information Exchange Terminology
Messages
Exchanged between the applications in the card and the Next Gen
Kernel at the Application Layer and at the Secure Channel Layer
Datagrams
Exchanged between the card and the Next Gen Kernel at the level of
the CAL. The CAL converts the Messages into the appropriate data
units for the communication protocol in use for this transaction.
PDUs
Exchanged between the card and the Next Gen Kernel at the Protocol
Layer, such as the APDUs defined by ISO/IEC 7816 Part 4
[ISO-7816-4], exchanged when using existing EMV Level 1 protocols
over the contact or contactless interfaces (per Book 1 of [EMV CT] and
Book D of [EMV CL]).
Figure 5-1 illustrates the communication layering.
Page 38
EMVCo Confidential
September 2014

5.1 Communication Between Kernel and Card
Figure 5-1: Next Gen Kernel Communication Layering
September 2014
EMVCo Confidential
Page 39
5.2 Data Exchange Within the Kernel
5.2

Data Exchange Within the Kernel
The exchange of data between Next Gen Kernel modules is described through the
mechanism of a Common Data Store (CDS) that manages, stores, and retrieves data
objects for the ongoing transaction.
Note: Although the different modules and the CDS are assumed to be running on the
same platform, use of the CDS is not mandated and modules can be distributed over
different platforms.
Note: The CDS is used only by the Application Layer modules. Neither the SCC
Manager nor the CAL obtain data from the CDS, nor do they store data objects in the
CDS.
At the start of the transaction, the Kernel Director populates the CDS with POI Systemsourced data and a subset of the configuration data. During transaction processing, each
module can retrieve data from the CDS and put updates into the CDS.
The Data Communication Manager retrieves data from the CDS to populate the messages
sent to the card. Various modules retrieve data from the CDS to include in events sent to the
POI System and populate the CDS with data obtained in events sent by the POI System.
Page 40
EMVCo Confidential
September 2014

5.3
5.3 Data Exchange Between Kernel and Card
Data Exchange Between Kernel and Card
Next Gen data objects are represented in a manner that is independent of the technologyspecific encoding techniques that may result from channel-specific restrictions (on
bandwidth, format, ).
Each Next Gen data object has an identifier and content. The data identifier is unique and
there is a strict binding between the identifier and the definition of the content.
5.3.1
Requesting Data Objects via DIL
As discussed in section 5.1, the Next Gen Kernel uses messages to exchange data objects
with the card at the Application Layer and the Secure Channel Layer. Figure 5-2 illustrates
the Next Gen message format.
Figure 5-2: Next Gen Message Basic Format
Each message contains (at least) one Data Identifier List (DIL). Data objects are requested
by including their identifiers in the DIL. If no data objects are requested in the current
message, the DIL is empty.
The receiver of the DIL provides the requested data objects in the next message. Figure 5-3
illustrates a basic Next Gen message exchange using a DIL.
September 2014
EMVCo Confidential
Page 41

Figure 5-3: Next Gen Data Exchange with DILs
When the receiver of a DIL parses the content, it may not recognize all data identifiers in the
DIL. For a data identifier that it recognizes, it may not have a value (yet). The fact that the
identifier was not recognized or that a value is not available (yet) is carried back in the return
message, and the data object may be asked for again in a subsequent message.
5.3.2
Requesting Data Objects via Queries
A data object can be requested by including the Identifier of the data object in the DIL. A
subset of a queryable data object can be requested through a Query applying some filtering
criteria.
For example, during Application Selection, the Selection Manager maintains a list of
available payment applications on the acceptance device, containing detailed information
about available TRM options (whether the transaction can be authorised online and/or
offline), CVMs that can be performed, and available additional services. The card may query
for various combinations of this list. For example, the card may ask for:
Each payment application that supports Offline PIN and cashback
Each payment application that supports Online Biometrics and uses a particular
Acquirer ID
All CVMs supported by a particular payment application.
Figure 5-4 illustrates a Next Gen message exchange including Queries.
Page 42
EMVCo Confidential
September 2014

Figure 5-4: Next Gen Data Exchange with Queries
September 2014
EMVCo Confidential
Page 43
6 Non-functional Requirements
6.1 Performance Requirements

Non-functional Requirements
This chapter covers performance requirements and requirements for terminal peripherals. It
also touches on testing and type approval for Next Gen.
6.1
Performance Requirements
EMVCo expects transactions executed with Next Gen Kernel to meet certain performance
requirements. These performance requirements are essential in achieving consistent
cardholder experience across different markets.
6.2
POI System Peripherals and User Interface
EMV POI Systems are considered to host various user interfaces for the cardholder and
merchant, including peripheral devices such as PIN pads and receipt printers. Physical
characteristics of the POI System and device components may vary depending on the
intended usage of the POI System and the environment at the point of transaction.
Requirements have been defined for:
Card readers
Data entry on the POI System, including command keys
PIN entry
Biometric data capture
Display
Audio
Printer
Clock
POI System configuration parameters
Page 44
EMVCo Confidential
September 2014

6.3
6.3.1
6.3 Testing and Type Approval
Testing and Type Approval

Card Testing and Type Approval Scope
The target of EMV Next Gen Card Type Approval is the NGSE application interface to a Next
Gen Kernel. EMVCo will define the corresponding test plan and testing procedures.
The actual on-card implementation of NGSE and its eventual interfaces with Next Gen Card
applications are out of scope of EMVCo and therefore out of scope of EMV Next Gen Card
Type Approval.
The Next Gen Card applications are out of scope of EMVCo and therefore out of scope of
EMV Next Gen Card Type Approval.
The Contact Legacy Card applications other than Common Payment Application (CPA) and
Common Core Definitions (CCD) applications, as well as the Contactless Legacy Card
applications, are not defined by EMVCo and therefore remain out of scope of EMV Card
Type Approval.
PPSE for contactless mobile payments, CPA and CCD Card applications are defined by
EMVCo in [AAUI], [EMV CT], and [CPA] and therefore remain in scope of EMV Card Type
Approval.
6.3.2
Terminal Testing and Type Approval Scope
The POI System as defined in section 2.1 is out of scope of EMVCo and thus out of scope of
EMV Next Gen Terminal Type Approval.
Therefore, the target of EMV Next Gen Terminal Type Approval is the Acceptance Device
described in section 2.1, minus the POI System; that is:
Kernel Director + Next Gen Kernel + Communication Abstraction Layer +
Protocol Layer Protocols
EMVCo will define the corresponding test plans and testing procedures.
The Legacy Contact Kernel, Legacy Contactless Kernel(s), Entry Point, and corresponding
contact and contactless Level 1 protocols are defined by EMVCo in [EMV CT] and [EMV CL]
and therefore remain in scope of EMV Terminal Type Approval.
September 2014
EMVCo Confidential
Page 45
6.3 Testing and Type Approval
6.3.3

Terminal Type Approval Process
Mixed Legacy and Next Gen Acceptance Devices

The Next Gen architecture employs a modular and layered design per the Next Gen project
objectives, as illustrated in Figure 2-1, where each of the following is an independent
module:
Kernel Director
Legacy Contact Kernel
Entry Point
Legacy Contactless Kernel(s)
Next Gen Kernel
Protocol Layer Utilities
The existing Terminal Type Approval in a Multi Kernels environment proposes two
processes: the Standard Process where full testing is required systematically and the
Optimized Process where testing is limited to the concerned module.
The Optimized Type Approval Process seems the most appropriate approach for the Next
Gen Acceptance Device described in section 2.1 due to the increase of complexity related to
the simultaneous support and management of both Legacy Kernels and the Next Gen
Kernel. The Optimized Process minimizes testing efforts in Multi Kernels environments such
as mixed Legacy and Next Gen Acceptance Devices during the migration period.
Next Gen Acceptance Devices

Because the Next Gen Kernel Architecture described in Chapter 2 uses a modular approach,
it may be possible to design an Optimized Process for testing the individual modules.
EMVCo will further investigate such a possibility.
Page 46
EMVCo Confidential
September 2014

7 Migration
Migration
This chapter discusses considerations related to migration from Legacy to Next Gen in
devices and cards.
The sections describe the following aspects of migration:
7.1
Application Selection ............................................................. 48
7.2
Kernel Director ...................................................................... 52
7.3
Data Objects ......................................................................... 55
7.4
Cryptography ........................................................................ 55
7.5
Communication Protocol ....................................................... 56
7.6
Future Evolution .................................................................... 57
Migration to Next Gen capability in both cards and acceptance devices is intended to be
allowed as part of the normal lifecycle of products in market. Thus, it is expected that cards
and acceptance devices based on Legacy specifications could coexist with those that
support Next Gen throughout the migration period. This enables the continuation of
deployment programs based on Legacy EMV specifications, and allows the usual card and
acceptance device replacement cycles to be retained.
Migration speed will be market driven.
New acceptance devices will include old and new Kernels.
New cards will include old and new applications.
Introduction of new data values/elements and network upgrades will be market and
Payment System driven.
September 2014
EMVCo Confidential
Page 47
7 Migration
7.1

Next Gen capable Acceptance Devices may encounter Legacy-only cards, and Next
Gen capable cards may encounter Legacy-only Acceptance Devices.
Cards are expected to support Legacy only or a mix of Legacy and Next Gen
applications. It is recommended that cards that support a Next Gen application also
support a Legacy equivalent to the Next Gen application for use on Acceptance
Devices that do not yet support the Next Gen application, but this is an
issuer/Payment System choice.
Note: A multi-application card that supports a Next Gen application (and potentially
its Legacy equivalent) for a particular issuer/Payment System may support a Legacyonly application for another specific issuer/Payment System. It is recommended that
Legacy-only applications on multi-application cards that support Next Gen be
registered on the card in both PPSE (or PSE) and NGSE in order to be included in
the application selection process by both Legacy and Next Gen Kernels.
Acceptance Devices are expected to support Legacy only or a mix of Legacy and
Next Gen applications. It is recommended that Acceptance Devices that support a
Next Gen application also support a Legacy equivalent to the Next Gen application
for use with cards that do not yet support that Next Gen application, but this is a
merchant/acquirer/Payment System choice.
Note: A multi-application Acceptance Device that supports a Next Gen application
(and potentially its Legacy equivalent) for a particular merchant/acquirer/Payment
System may support a Legacy-only application for another specific
merchant/acquirer/Payment System. It is recommended that Legacy-only
applications on multi-application Acceptance Devices that support Next Gen have
their pre-processing parameters properly configured in both Legacy and Next Gen
Kernels in order for the application selection process by both Legacy and Next Gen
Kernels to be performed accurately.
It is assumed that the cardholder presents the card for use over the cardholders preferred
interface, and that switching interfaces is less desirable for the cardholder than completing
the transaction over the current interface. Thus, the priority of the Next Gen application
selection process is to find a mutually supported application to use over the interface being
used for application selection, even if that is a Legacy application rather than a Next Gen
application. The Next Gen application selection process attempts to switch interfaces when
there is no mutually supported application available on the current interface.
If the acceptance device is not capable of Next Gen, it performs Legacy processing as
already defined by EMVCo.
Page 48
EMVCo Confidential
September 2014

7 Migration
If the acceptance device is capable of Next Gen, it attempts to perform application selection
using the Next Gen application selection process. This application selection process
manages selection of both Legacy and Next Gen applications on the card, and could result
in:
Choosing to use a Next Gen application on the card.
Choosing to use a Legacy application on the card.
Suggesting that the cardholder switch interfaces to attempt the transaction using an
application available on another interface, because there is no acceptable application
on the current interface.
Not finding any mutually supported application, and terminating the transaction.
The Next Gen configuration parameters include the information that is needed for both
Legacy and Next Gen Kernel configuration. Pre-processing in the Next Gen Kernel includes
the pre-processing that would be done for any Legacy Kernel that is supported in the Next
Gen application selection process. This assumes that the necessary pre-processing
parameters for Legacy Kernels would be appropriately configured in the Next Gen Kernel.
This ensures that if the outcome of Next Gen application selection is to use a Legacy Kernel
to process the transaction, the Legacy Kernel does not need to perform an additional round
of pre-processing the information that would have come from Legacy pre-processing is
obtained as a result of Next Gen pre-processing. This may require small modifications to
Legacy contact Kernel and Entry Point specifications (currently under investigation by
EMVCo, as well as the transformation between Legacy and Next Gen pre-processing
parameters). However, it optimizes transaction performance, resulting in minimum impact on
existing Legacy processing when introducing Next Gen into the device. It is anticipated that
changes could be implemented in Legacy contact Kernel and Entry Point implementations to
prepare them for later introduction of a Next Gen Kernel.
A Next Gen application in a card or acceptance device can be linked to an associated
Legacy application in the same card or device, by using the same Service Identifier (SvID) 3
for both the Next Gen and the associated Legacy application. Thus, a single SvID in a card
or acceptance device can support only Next Gen functionality, only Legacy functionality, or
both Next Gen and Legacy functionality. This association allows the Next Gen application to
be used if it is mutually supported between the card and acceptance device; but if the Next
Gen application is not mutually supported, the associated Legacy application could be used
instead if it is mutually supported. If a Next Gen application and a Legacy application have
the exact same SvID, they are considered associated for application selection, and
preference is always given to using the Next Gen application if possible. Thus, if both the
Next Gen application and the associated Legacy application are mutually supported between
the card and device, the Next Gen application is used for processing the transaction.
A Service Identifier (SvID) identifies an application, particularly the NGSE or a payment application.
September 2014
EMVCo Confidential
Page 49
7 Migration

As illustrated in Figure 7-1:
If an acceptance device supports only a Next Gen Kernel, it interacts only with the
corresponding Next Gen application in cards. (The card may support only the Next
Gen application, or may support both the Next Gen and Legacy applications.)
If an acceptance device supports only a Legacy Kernel, it interacts only with the
corresponding Legacy application in cards. (The card may support only the Legacy
application, or may support both the Next Gen and Legacy applications.)
If an acceptance device supports both a Next Gen and the associated Legacy
Kernel, and the card supports both the corresponding Next Gen application and the
associated Legacy application, the Next Gen Kernel interacts with the Next Gen
application in the card to process the transaction.
Figure 7-1: Application Selection Overview
So that a Legacy Kernel does not attempt to work with a Next Gen-only application:
The Next Gen-only application is not listed in the PPSE or PSE.
The NGSE and Next Gen-only applications reject Legacy SELECT commands.
Page 50
EMVCo Confidential
September 2014

7 Migration
If the Selection Manager determines that a Legacy application will be used for the
transaction, the Selection Manager maps the SvID and optional SvID Extension for the
chosen application to the AID value to use for the final SELECT command. This AID, the
Kernel ID (recovered from the NGSE), and the interface used (reported by the CAL) are
passed to the Kernel Director for processing the Legacy transaction.
September 2014
EMVCo Confidential
Page 51
7 Migration
7.2 Kernel Director
7.2

Kernel Director
A POI System only needs to know it wants to do an EMV payment transaction it should be
transparent to the POI System whether the transaction is performed using a Next Gen or
Legacy Kernel. Thus, at least during the migration period, the POI System interacts with the
Kernel Director in a Next Gen capable acceptance device.
The Kernel Director manages switching from Next Gen to a Legacy Kernel as a result of
application selection, and directs the interaction between the POI System and the Kernel
chosen to process a specific transaction. When all cards and all terminals are Next Gen-only
(that is, they do not support any Legacy applications), the Kernel Director may be simplified
to only manage the transition from Application Selection to Transaction Processing.
In more detail, the Kernel Director first initiates Application Selection and then handles the
outcome as follows:
If the card is Next Gen capable and a Next Gen application is selected, the Kernel
Director:
o
Initiates a Next Gen transaction with the Next Gen Kernel.
Routes subsequent messages between the Next Gen Kernel and the POI System
until the transaction is complete and the clearing record has been sent to the POI
System.
If the card is Next Gen capable, but the selected application needs to be processed
by a Legacy Kernel, the Kernel Director:
o
Initiates the Legacy contact Kernel or Entry Point, and provides the selected
combination in the Entry Point format and the Entry Point Pre-Processing
indicators (this avoids the need for Legacy application selection processing to
take place, as the final application to use is already chosen by the Next Gen
application selection processing).
Routes subsequent messages between the chosen Legacy Kernel and the POI
System until the transaction is complete and the clearing record has been sent to
the POI System.
If the Legacy Kernel processing results in an outcome that would send the
Legacy Kernel back to Application Selection (for example, the contact card
responds to the GET PROCESSING OPTIONS command with an error), the Kernel
Director removes from the candidate list the application that resulted in the error
outcome, and returns to the Selection Manager to request that the next eligible
application be chosen.
If the card is not Next Gen capable:

o
Page 52
If the card is presented on the contact interface, the Kernel Director initiates the
Legacy contact Kernel to do its own application selection.
EMVCo Confidential
September 2014

7 Migration
7.2 Kernel Director
If the card is presented on the contactless interface, the Kernel Director initiates
the Legacy contactless Entry Point to do its own application selection and select
the appropriate Legacy contactless Kernel.
The Kernel Director routes subsequent communications between the chosen

Legacy Kernel or Entry Point and the POI System until the transaction is
complete and the clearing record has been sent to the POI System.
EMVCo is investigating possible small modifications to Legacy contact Kernel and Entry
Point specifications that would enable the Kernel Director to inform the Legacy Kernel to
initiate transaction processing directly with the final AID, bypassing the usual pre-processing
and application selection processing in Legacy Kernels today. It may be possible to
incorporate these minor modifications into Legacy Kernels before the Next Gen
specifications are complete, allowing vendors to make Legacy products ready for easier
addition of Next Gen capabilities at a later date.
7.2.1
Application Selection Considerations for Legacy Kernels
In order to prevent duplication of processing, and to minimize the overall impact on Legacy
transaction times when introducing Next Gen capability to a terminal that supports Legacy
Kernels, the Next Gen Kernel Director transforms the pre-processing results for a Next Gen
transaction to their equivalent for Legacy transaction pre-processing. This avoids the need
for the Kernel to perform Legacy pre-processing when the Kernel Director determines that a
Legacy contactless Kernel will be used for the transaction. As needed, the Kernel Director
also transforms any Next Gen transaction details to the equivalent Legacy EMV transaction
details.
If the transaction being processed with a Legacy Kernel cannot be completed, and the
resulting action specified for the Legacy Kernel is to terminate the transaction, then the
Legacy Kernel indicates to the Kernel Director that the transaction must be terminated. The
Kernel Director then Closes the Selection Manager and terminates the transaction.
If the transaction being processed with a Legacy Kernel cannot be completed, and the
resulting action specified for the Legacy Kernel is to remove the application from the
candidate list and resume final selection, then the Legacy Kernel indicates to the Kernel
Director that the transaction cannot complete and that Application Selection must be
resumed. The Kernel Director then requests that the Selection Manager remove the
application that was selected, and choose a new application 4. This new selection may result
in selection of a Legacy application, or may result in selection of a Next Gen application
(that is, it is not restricted to choosing only a Legacy application because the failed
application was Legacy).
If Next Gen Application Selection results in choosing a Legacy Kernel to process the transaction,
Selection Manager must retain the candidate list of mutually supported applications to handle
scenarios where Legacy processing terminates the transaction and returns to application selection to
choose the next application in the candidate list.
September 2014
EMVCo Confidential
Page 53
7 Migration
7.2 Kernel Director

Examples of Legacy contact chip transactions that result in a return to Application Selection
include:
The final SELECT command response Status Word is not '90 00'.
The GET PROCESSING OPTIONS command response Status Word has the value
'69 85'.
There is a format error in the FCI.
Examples of Legacy contactless chip transactions that result in a return to Application

Selection include:
Select Next Outcome
Try Another Interface Outcome
Page 54
EMVCo Confidential
September 2014

7.3
7 Migration
7.3 Data Objects
Data Objects
EMV Next Gen is expected to provide richer data about the transaction between cards and
acceptance devices, and to enable more data to be sent between cards, acceptance
devices, acquirers, and issuers. This is expected to require upgrades to issuer, acquirer, and
processor host systems and acquiring infrastructure to carry more data. It is also expected to
require upgrades to Payment System services such as stand-in processing and
authentication services to support the new and modified data for Next Gen transactions.
In section 2.2.2, EMVCo describes the functionality of the Adaptation Layer as a mechanism
for interpreting and transforming proprietary data format to and from the Next Gen data
format. This Adaptation Layer is primarily a tool to facilitate the integration of Next Gen
Kernel to an existing acceptance device.
7.4
Cryptography
Symmetric cryptography is used between the card and issuer, and thus the cryptographic
mechanism supported is out of scope for EMV Next Gen specifications. It is up to the
Payment System and issuer to choose the mechanism for cryptography between the card
and issuer. EMV Next Gen specifications will define data objects that can carry the data
between the card and acceptance device, which could be used to carry the cryptogram and
other data used by the Payment System or issuer, such as data used to generate the
cryptogram, and data used for stand in processing on behalf of the issuer.
EMV specifications fully define the public key cryptography for offline authentication of the
card and of the data exchanged between cards and acceptance devices. Legacy EMV public
key cryptography uses RSA. EMV Next Gen supports only ECC for public key cryptography.
Thus during the migration period Payment Systems that support any functionality that uses
public key cryptography may need to support both RSA and ECC in their Certificate
Authority and key management infrastructure. It is up to Payment Systems to plan for
updates to their Certificate Authorities to support ECC public key cryptography.
September 2014
EMVCo Confidential
Page 55
7 Migration
7.5 Communication Protocol
7.5

Communication Protocol
Figure 7-2 illustrates how the Next Gen Kernel and the Legacy Kernel share the same
Protocol Layer so that communication can be maintained while switching between Next Gen
and Legacy.
The Next Gen Kernel uses the full functionality of the CAL and can bind to communication
protocols other than ISO 7816-4. The Legacy Kernel uses only the Connectivity Utility and
binds only to ISO 7816-4.
Through the Connectivity Utility, the Legacy Kernel can detect a card, activate the protocol,
send APDUs, deactivate the protocol, and check whether the card has been removed. All
commands, including the SELECT command, are sent using the SendDatagram request.
Figure 7-2: Next Gen and Legacy Sharing the Protocol Layer
Page 56
EMVCo Confidential
September 2014

7.6
7 Migration
7.6 Future Evolution
Future Evolution
The Next Gen specifications may evolve in the future. To ensure forward compatibility with
future versions, a Kernel version agreement mechanism between the Next Gen Kernel and
the card is under consideration. This mechanism would allow negotiating both the Kernel
version to be used during the application selection phase and/or the Kernel version to be
used during the transaction processing phase of a Next Gen transaction 5. A similar
mechanism may be considered for the secure channel protocol.
The mechanism under consideration would require additional versioning information to be

exchanged between the Next Gen Kernel and the card though without requiring any additional
message. [Next Gen] v1.0 does not include such version agreement mechanisms nor the
corresponding versioning information.
September 2014
EMVCo Confidential
Page 57
Annex A References

Annex A References
This section lists references mentioned in this document.
Table A-1: References
Reference
Document Title
[Next Gen]
EMV Next Generation Kernel System Specifications for Payment

Systems
[EMV CT]
EMV Integrated Circuit Card Specifications for Payment Systems

**#** nothing in this book is specific enough (deliberately) to need
these version numbers
[EMV CL]
EMV Contactless Specifications for Payment Systems
[CPA]
EMV Common Payment Application Specification
[AAUI]
EMVCo Contactless Mobile Payment Application Activation User

Interface Overview, Usage Guidelines, and PPSE Requirements
[ISO-7816-4]
ISO/IEC 7816 Part 4 Identification cards Integrated circuit cards

Part 4: Organization, security and commands for interchange
Page 58
EMVCo Confidential
September 2014

Annex B Abbreviations and Terminology

Table B-1: Abbreviations and Terminology
Acceptance Device
In the context of EMV Next Gen:
Includes the POI System
Includes the functionalities necessary for card

interaction: the Next Generation Kernel, the
Communication Abstraction Layer, and the
Protocol Layer protocols
Includes the Kernel Director

o
Hosts Legacy Kernels for contact and

contactless as appropriate
AID
Application IDentifier
AL
Application Layer
APDU
Application Protocol Data Unit
In the context of the Next Gen specifications, refers

to processing that is done to choose the application
and determine whether the transaction will be
conducted as Next Gen or Legacy.
ATM
Automated Teller Machine
CAL
Communication Abstraction Layer; provides services

related to communication with the card. Includes:
Session Management Utility
Connection Management Utility
Link Management Utility
Binding Utility
Card
In the context of the Next Gen specifications, unless

otherwise specified, card refers to contact cards,
contactless cards, and mobile phones.
Cardholder Verification Manager
See CV Manager.
September 2014
EMVCo Confidential
Page 59

CCD
Common Core Definitions
CDIL
Card DIL; the list of data objects requested from the

Next Gen Card.
CDS
Common Data Store
Common Core Definitions
A minimum common set of card application

implementation options, card application behaviours,
and data element definitions sufficient to accomplish
an EMV transaction; an optional extension described
in [EMV CT].
Common Data Store
A Next Gen Application Layer utility that manages,

stores, and retrieves transaction data objects
accessible to one or more modules.
Common Payment Application
A functional description of an application that

complies with the EMV Common Core Definitions
(CCD) requirements; see [CPA].
See CAL.
Core EMV Functionality
Selected processing by an EMV Acceptance Device,

including all dialogue with the card and preparation of
data required for network messaging (in Legacy
EMV, known as Level 2).
CPA
Common Payment Application
CV
Cardholder Verification
CVM
Cardholder Verification Method
CV Manager
Cardholder Verification Manager; provides services

related to cardholder verification, then provides the
Transaction Manager with its position on the
transaction (for example, whether the transaction can
be conducted offline or must be sent online).
Performs services relating to data exchange with an

external entity.
Data Identifier List
See DIL.
Page 60
EMVCo Confidential
September 2014

DCM
DIL
Data Identifier List; list of data objects requested from

the recipient of a message. Named after its receiver;
see CDIL and KDIL.
ECC
Elliptic Curve Cryptography
Entry Point
Performs initial analysis of a Legacy contactless

transaction and invokes appropriate Kernel software,
as described in [EMV CL].
I/O
Input / Output
IEC
International Electrotechnical Commission
ISO
International Organization for Standardization
Acts as the proxy for the issuer to perform data

analysis for transaction authorisation purposes,
primarily when the card is no longer available to
perform these tasks, then provides the Transaction
Manager with its position on the transaction (for
example, whether the transaction can be conducted
offline or must be sent online).
KDIL
Kernel DIL; the list of data objects requested from the

Next Gen Kernel.
Kernel
Module that provides overall control of transaction

processing in a given context.
See Next Gen Kernel, Legacy Contact Kernel, and
Legacy Contactless Kernel.
Kernel Director
September 2014
Module that initiates the selected card application on

the appropriate Kernel.
EMVCo Confidential
Page 61
Kernel Services

Modules, each responsible for a self-contained

function or functions, that may interact with other
services or utilities. Includes:
CV Manager
TR Manager
PAS Manager
PRD Manager
SCC Manager
Legacy
Refers to transaction processing as described in

[EMV CT] or [EMV CL].
Legacy Contact Kernel
Module that controls transaction processing as

described in [EMV CT].
Legacy Contactless Kernel
Module that controls transaction processing as

described in [EMV CL].
Next Gen
Refers to transaction processing as described in

EMV Next Generation Kernel System Specifications
for Payment Systems ([Next Gen]).
Next Gen Application Layer

Utilities
Modules, including the Common Data Store, that

provide general operations at the Application Layer
Next Gen Kernel
The combination of:
Next Gen Protocol Layer Utilities
Next Gen Systems Environment

Page 62
Selection Manager
Transaction Manager
Kernel Services
Next Gen Application Layer Utilities
Modules that provide general operations at the

Protocol Layer:
Contact Communication Protocol Manager
Contactless Communication Protocol Manager
See NGSE.
EMVCo Confidential
September 2014

NGSE
Next Gen Systems Environment; a card application

that provides the Next Gen Kernel with dynamic
information regarding the payment applications
available on the card.
PAN
Primary Account Number
PAS
Payment Additional Services
PAS Manager
Payment Additional Services Manager; module that

provides additional payment services for EMV
transactions.
Payment Additional Services

Manager
See PAS Manager.
Payment Related Data Manager
See PRD Manager.
PCI
Payment Card Industry
PCI SSC
PCI Security Standards Council
PDU
Protocol Data Unit
PIN
Personal Identification Number
PL
Protocol Layer
POI
Point Of Interaction
POI System
Point of Interaction System; the part of the

Acceptance Device that provides interaction for card
acceptance at physical locations.
Point of Interaction System
See POI System.
PR
Payment Related
PRD
Payment Related Data
PRD Manager
Payment Related Data Manager; module that

provides services related to the transfer of additional
data between the card and POI System, then
provides the Transaction Manager with its position on
the transaction (for example, whether the transaction
can be conducted offline or must be sent online).
September 2014
EMVCo Confidential
Page 63

Protocol Layer
Provides lower level communication to contact and/or

contactless cards and/or mobile phones.
Queryable Data Object
A data object that includes one or more instances of

a primary data object and, for each instance, one or
more parameters with values that are associated with
the primary data object.
SCC
Secure Card Channel
SCC Manager
Secure Card Channel Manager; module that

performs services related to data protection and card
authentication.
SCL
Secure Channel Layer
Secure Card Channel Manager
See SCC Manager.
Selection Manager
If the card has an NGSE, determines whether the

card has an appropriate application to perform the
payment transaction.
SvID
Service ID; identifies an application, particularly the

NGSE or a payment application
TCP/IP
Transmission Control Protocol / Internet Protocol
Terminal Risk Manager
See TR Manager.
TPDU
Transport Protocol Data Unit
Transaction Manager
Oversees the Next Gen Application Layer session,

beginning once the payment application has been
selected.
Transaction Processing
In the context of the Next Gen specifications, refers

to processing performed after determining the
application to be used and whether the transaction
will be conducted as Next Gen or Legacy.
TRM
Terminal Risk Management
Page 64
EMVCo Confidential
September 2014

TR Manager
September 2014
Terminal Risk Manager; module that performs risk

checks and provides the Transaction Manager with
its position on the transaction (for example, whether
the transaction can be conducted offline or must be
sent online).
EMVCo Confidential
Page 65

EMV Next Gen Architecture Overview v1.0 201409160406534

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

EMV Next Gen Architecture Overview v1.0 201409160406534

Enviado por

Direitos autorais:

Formatos disponíveis

EMV*

Next Generation Kernel System

EMV Next Generation Kernel System

EMV Next Generation Kernel System

Document Organization .......................................................................................... 7

System Architecture ..................................................................................................... 8

Overview of Structure ............................................................................................. 8

Acceptance Device ............................................................................................... 11

Kernel Director ..................................................................................................... 15

Next Gen Kernel ................................................................................................... 16

POI System vs. Acceptance Device ....................................................... 12

Architecture Principles ........................................................................... 16

Next Gen Systems Environment (NGSE) ............................................................. 21

Next Gen Security ....................................................................................................... 23

Next Gen Kernel to Card Security......................................................................... 24

Secure Channel ..................................................................................... 24

Card to Issuer Security ......................................................................................... 27

Card Authentication and Transaction Data Integrity ............................... 27

POI System Security Considerations .................................................................... 28

Additional Considerations ..................................................................................... 29

EMV Next Generation Kernel System

Processing Sequence ................................................................................................. 30

Overall Processing Sequence .............................................................................. 30

Application Selection ............................................................................................ 32

Transaction Processing ........................................................................................ 34

Communication Layering ........................................................................................... 38

Communication Between Kernel and Card ........................................................... 38

Data Exchange Within the Kernel ......................................................................... 40

Data Exchange Between Kernel and Card ........................................................... 41

Requesting Data Objects via DIL ........................................................... 41

Non-functional Requirements .................................................................................... 44

Performance Requirements .................................................................................. 44

POI System Peripherals and User Interface ......................................................... 44

Testing and Type Approval ................................................................................... 45

Next Gen Detection................................................................................ 32

Card Testing and Type Approval Scope ................................................. 45

Application Selection ............................................................................................ 48

Kernel Director ..................................................................................................... 52

Application Selection Considerations for Legacy Kernels ....................... 53

Communication Protocol ...................................................................................... 56

Future Evolution ................................................................................................... 57

Abbreviations and Terminology .................................................................... 59

EMV Next Generation Kernel System

EMV Next Gen Acceptance Device .................................................................... 9

Functional Responsibilities of Acceptance Device ............................................. 13

EMV Next Generation Kernel System

Enhancing transaction information available to acquirers, networks, and issuers

Future proofing EMV security by incorporating next generation public key

Supporting multiple communication protocols, with the flexibility to add additional

Integrating Type Approval processes for contact and contactless

EMV Next Generation Kernel System

This document includes the following chapters and annexes.

EMV Next Generation Kernel System

Card communication, previously known as Level 1 Provides application

EMV Next Generation Kernel System

Figure 2-1: EMV Next Gen Acceptance Device

Acceptance Device In the context of EMV Next Gen, includes:

Core EMV Functionality:

During the migration period:

Legacy Kernels for contact and contactless as appropriate

Next Generation Kernel

Communication Abstraction Layer

Protocol Layer protocols

EMV Next Generation Kernel System