Professional Documents
Culture Documents
Table of Contents
1 Introduction ................................................................................................... 3
7 References ................................................................................................... 33
1 Introduction
DKV Mobility Services Business Center GmbH & Co KG (DKV) , further on also called DKV,
is a Europe wide service provider for customers in the transport and mobility sector. DKV
provides its customers a broad supply of services for cashless payments, especially at
service stations and tollways. DKV issues the "DKV Card" for commercial road vehicles, and
NOVOFLEET cards for passenger vehicles. Both cards are currently magnetic stripe based
and will be migrated to chip cards based on EMV.
This document contains the requirements for the EMV fuel cards issued by DKV, these cards
are called DKV cards.
A DKV card has to comply with the EMV specification [CPA]. If not stated otherwise no
optional additional functionality of [CPA] has to be supported. Since the DKV cards are
compliant to [CPA] they are compliant to the EMV Common Core Definitions (CCD).
In a first step a fuel card supporting the magnetic stripe and an ICC with contacts will be
issued. In a second step a dual interface card will follow. Dual interface cards support
transmission both over the contact and the contactless interface. As soon as the magnetic
stripe will not be necessary any more to process the transactions, it can be dispensed.
Contact only cards only need to support one profile and dual interface cards need to support
two profiles. The card has to be able to identify the interface used to select the application.
Dual interface cards may optionally support a Mifare Emulation if it is needed for additional
service.
The following implementer options listed in section 5.1 of [CPA] shall be supported/not
supported by a DKV card:
• (For Dual-Interface Cards) Profile Selection Using Card Data shall be supported.
The risk management of the DKV card forces – if the terminal is online capable - always an
online transaction. In the exceptional case when online processing is not possible, e.g. at
offline only terminals, a transaction may be performed offline, but only if the transaction is
performed over the contact interface. Therefore Accumulator 1 contains the cumulative
amount of all offline approved contact Euro transactions with Offline PIN as CVM that were
processed since the last reset of Accumulator 1. In addition a cyclic Accumulator is used to
limit the offline Limit to a daily available limit.
If the DKV card is accepted by a terminal which supports the DKV card application, the
transaction must be performed ICC based. If the DKV fuel card does not support an ICC or
the ICC does not work the DKV card allows magnetic stripe processing.
Typically a DKV cards will be valid for 5 years (year of issuance + 4 years). Only cards
having a valid EMVCo Type Approval and a valid security certificate of EMVCo (CAST) or of
GBIC will be used.
The following diagram shows the various parties and systems involved in key management
and card personalisation.
Co-
branding
Card
manufacturer
The Key Administration Centre (KAC) generates the symmetric master keys, which have to
be distributed to the Authorisation System and the Data Preparation System.
The Certification Authority (CA) generates the issuer public key certificates with the CA
public key(s). The issuer public key certificates are distributed to the Data Preparation
System for personalisation in the card. The CA public keys are distributed to the terminals to
verify the issuer public key certificates.
The SAP KMS distributes the card data over the so called "personalisation bureau interface"
([DKV PBI]) to the Data Preparation System.
The following AIDs may be supported by the DKV Card Application. The AID is contained in
position 43 of the SK-Satz in the "personalisation bureau interface" ([DKV PBI]).
The Application Label assigned to an AID in the FCI Proprietary Template may be displayed
by an EMV terminal in order to inform the cardholder of the current application during
Application Selection or later during the transaction. The following table describes the
Application Label defined for the supported AIDs.
2.2 PSE
The card shall contain a Payment System Environment (PSE) as described in [EMV 1]
section 12. In the PSE all applications that are accessible over the contact interface are
listed. Every application is listed in the PSE in a directory entry. The following table describes
the data objects contained in each directory entry for the DKV Card Application.
The Application Priority Indicator (API) is present in all FCI Proprietary Templates defined for
the DKV Card Application application. Table 4 shows the coding of the API as defined in
section 12.2.3 of [EMV 1].
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x - - - - - - - Cardholder confirmation requirement
1 - - - - - - - Application cannot be selected without confirmation of the
cardholder
0 - - - - - - - Application may be selected without confirmation of the
cardholder
- x x x- - - - - RFU
- - - - 0 0 0 0 No priority assigned
- - - - x x x x Order in which the application is to be listed or selected,
ranging from 1–15, with 1 being highest priority
Consequently, the cardholder will only be asked to select a language at an EMV terminal, if
the terminal supports neither "Language 1" nor English display messages.
Within the DF_PSE in an EF - referenced by the SFI contained in the FCI of the PSE (see
Table 5) - one or several directory entry templates describing the fuel card application(s)
contained in the card are stored.
2.3 PPSE
Dual interface cards shall also contain a Proximity Payment System Environment (PPSE) as
described in [EMV B] section 3.3. All applications that are accessible over the contactless
interface can be found by selecting the PPSE. Every application is listed in the FCI of the
PPSE in a directory entry in the FCI Issuer Discretionary Data. The following table describes
the FCI returned upon the selection of the PPSE, if only one application is supported and
therefore only one directory entry (DKV Directory Entry Template) is contained in the FCI
Issuer Discretionary Data.
The card shall support the commands listed in table 5-3 in [CPA] section 5.4.2.
In accordance with [CPA] (section 18.5.3) all issuer script commands require secure
messaging and the application considers all commands received with secure messaging to
be script commands.
The cryptogram version of the card shall be '5' (which uses Triple DES). Therefore the
following requirements for secure messaging and application cryptogram generation apply.
MAC computation:
• shall use Secure Messaging Format 1 as described in section 9.2.1.1 of [EMV B2]
and
• shall chain the MACs from one command to the next according to the method
recommended in section 9.2.3.1 of [EMV B2].
Secure messaging Format 1: Secure messaging format according to ISO/IEC 7816-4, where
the data field of the affected command uses Basic Encoding Rules-Tag Length Value (BER-
TLV) encoding and encoding rules of ASN.1/ISO 8825-1 apply strictly. This is explicitly
specified in the lowest significant nibble of the class byte of the command, which is set to 'C'.
This also implies that the command header is always integrated in MAC calculation.
The MAC shall be generated using the MAC algorithm specified in [EMV B2], Annex A1.2.1,
Step 3, second bullet using DES as the block cipher.
As described in [EMV B2] the MAC Session Key shall be derived using the method specified
in Annex A1.3.1 of [EMV B2].
[CPA] section 18 describes the coding of the script commands and whether the command
data shall be enciphered.
Data that is enciphered in the Issuer Script Command data field shall always be padded
before encipherment. The Padding Indicator byte shall be included and shall be set to the
value '01' to indicate padding is present.
The Encipherment Session Key shall be derived using the method specified in Annex A1.3.1
of [EMV B2].
Encipherment/decipherment of the command data field shall use the Cipher Block Chaining
(CBC) Mode described in [EMV B2], Annex A1.1. The Triple DES algorithm specified in
[EMV B2], Annex B1.1 is used. The Padding Indicator byte is set to the value '01' to indicate
that padding is present.
Application Cryptogram
As described in [EMV B2] the Application Cryptogram (AC) in the response of the
GENERATE AC command shall be 8-bytes. Application Cryptograms shall be generated
using the MAC algorithm specified in [EMV B2], Annex A1.2.1 and ISO/IEC 9797-1 Algorithm
3 with DES, and s=8.
Table CCD 3 in [EMV B2] lists the set of data elements to be included in the Application
Cryptogram.
As described in [EMV B2] the AC Session Key shall be derived using the method specified in
Annex A1.3.1 of [EMV B2].
2.5.1 PSE
SFI '15' is defined for the EF_LOG with the Log entries.
SFI '16' is defined for the EF_PST with the Profile Selection entry on Dual Interface Cards.