You are on page 1of 10

Introduction

DKV CARD specification

DOCUMENT REVISION SHEET


Version Date Author chapter Details, reason for changes

1.0 21.03.2013 Project team all First official specification


1.1 10.02.2016 Project team all Various adjustments
1.11 19.09.2016 Uwe Broschk 5.1.1 Adjustment currency conversion rates
1.12 28.10.2016 Project team Annex 1 Correction coding track 3
1.13 15.11.2016 Project team all Various adjustments, more detailed
description in specific chapters
1.14 03.01.2017 Project team 5.1.1 - Pin Try Limit added (Tag 'C6')
- Correction of Tag BF3B
1.14 08.09.2017 Project team 5.12 - Correction of data in personalisation
buereau interface (data object PAN in
table 17 + 19)
1.15 06.06.2018 Project team all Chip identifier set to 2
1.16 04.07.2018 Project team 3.1 Fuel Card Data corrected
Correction SK-Satz position
1.17 10.08.2018 Project team 5.1.1 Correction of AIP/AFL Entry
1.18 05.02.2020 Project Team all Project Chip Card, Changes of structure
1.19 06.03.2020 Project Team 6.4 Translation title + description
1.20 29.03.2021 Project Team 6 Magnetic Track Structure (chapter 6).
Change of fallback description
1.21 15.11.2021 Project Team 3.2 Description of offline chip processing
adjusted

Version 1.21 | 15.11.2021 / Verantwortlich: Broschk, Uwe

DKV Card Specification1 | 15.11.2021 Page 1


Version 1.21
Introduction Fehler! Verweisquelle konnte nicht gefunden werden.

Table of Contents

1 Introduction ................................................................................................... 3

2 General Card requirements........................................................................... 5


2.1 Supported AID ................................................................................................. 5
2.2 PSE ................................................................................................................. 5
2.3 PPSE ............................................................................................................... 7
2.4 Commands and Secure Messaging ................................................................. 8
2.5 Defined SFI ................................................................................................... 10
2.5.1 PSE ............................................................................................................... 10
2.5.2 DKV Card Application ................................................................................... 10

3 DKV Card Application ................................................................................ 11


3.1 Fuel Card Data .............................................................................................. 12
3.2 Risk Management Data ................................................................................. 13

4 Key Management and Certification Authority............................................ 15


4.1 Asymmetric Keys ........................................................................................... 15
4.2 Key Management .......................................................................................... 16

5 Card Data Description ................................................................................. 18


5.1 CPA Data ...................................................................................................... 18
5.1.1 Internal Card Data ......................................................................................... 18
5.1.2 Data Referenced by the AFL ......................................................................... 23
5.1.3 Profile Selection Entry ................................................................................... 27
5.1.4 Log Entry ....................................................................................................... 27
5.2 Additional Tables ........................................................................................... 28
5.2.1 CIACs ............................................................................................................ 28

6 Magnetric track structure ............................................................................ 29


6.1 Coding of Track 1 .......................................................................................... 30
6.2 Coding of Track 2 .......................................................................................... 31
6.3 Coding of Track 3 .......................................................................................... 31
6.4 Calculation of the license plate number ......................................................... 32

7 References ................................................................................................... 33

Page 2 DKV Card Specification1 | 15.11.2021


Version 1.21
Introduction

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:

• The implementer options Dynamic-RSA and Application Security Counters

• (For Dual-Interface Cards) Profile Selection Using Card Data shall be supported.

• The implementer option VLP is not supported.

• The implementer option EMV CPS may 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.

DKV Card Specification1 | 15.11.2021 Page 3


Version 1.21
Introduction Fehler! Verweisquelle konnte nicht gefunden werden.

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.

Currently DKV card shall only be issued in Euro.

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.

Issuer Public Key


CA Public Key Certificate(s)
Terminal CA
KAC

symmetric Masterkeys „Prägeschnittstelle“


SAP
KMS

Zuordnung UID- Kartennummer Data


Authorisation Preparation
System

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.

Page 4 DKV Card Specification1 | 15.11.2021


Version 1.21
General Card requirements

2 General Card requirements

2.1 Supported AID

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]).

AID AID Name Presence


RID PIX
'A0 00 00 06 68' '00 00 00 00 02 76' DKV AID conditional
(international RID of (DKV PIX)
DKV) '00 00 00 01 02 76' Novofleet AID conditional
(Novofleet PIX)
Table 1: Supported AIDs

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.

AID Application Label


RID PIX
'A0 00 00 06 68' '00 00 00 00 02 76' "DKV EUROSERVICE"
(international RID of (DKV PIX)
DKV) '00 00 00 01 02 76' "NOVOFLEET"
(Novofleet PIX)
Table 2: Application Label in the FCI Proprietary Templates of the DKV Card
Application

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.

Tag Length Value


'4F' 5–16 ADF Name
'50' 1–16 Application Label
'87' 1 Application Priority Indicator
Table 3: Coding of the directory entry DKV Card Application

DKV Card Specification1 | 15.11.2021 Page 5


Version 1.21
General Card requirements Fehler! Verweisquelle konnte nicht gefunden werden.

Application Priority Indicator

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

Table 4: Coding of the Application Priority Indicator as Defined in Section 12.2.3 of


[EMV 1]
The following table defines the FCI of the PSE returned in the response to the SELECT
command (section 11.3.4 of [EMV 1]):

Tag Length Value Description


(in bytes)
'6F' var. Tag and length of FCI
'84' '0E' '31 50 41 59 2E 53 59 53 2E DF name of the DF_PSE
44 44 46 30 31' "1PAY.SYS.DDF01"
'A5' var. proprietary information
'88' '01' '01' SFI of the Directory Elementary File
'5F2D' '04' 'XX XX 65 6E' Language Preference (XX en) ISO 639
coded The language of the customer is
contained in position 16 of the KD-Satz in
the "personalisation bureau interface"
([DKV PBI]).
Table 5: FCI of the PSE returned in the response to the SELECT command

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.

Page 6 DKV Card Specification1 | 15.11.2021


Version 1.21
General Card requirements

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.

DKV Directory Entry Template

Table 6 shows the coding of the DKV Directory Entry Template.

Tag Length Value Description


(in bytes)
'61' '21' Directory entry template, tag and length
'4F' '0B' 'A0 00 00 06 68 00 00 00 00 DKV AID
02 76'
'50' '0F' "DKV EUROSERVICE" Application label
(ASCII: '44 4B 56 20 45 55 52
4F 53 45 52 56 49 43 45')
'87' '01' '01' Application Priority Indicator
Table 6: DKV Directory Entry Template

NOVOFLEET Entry Template

Table 7 shows the coding of the NOVOFLEET Directory Entry Template.

Tag Length Value Description


(in bytes)
'61' '1B' Directory entry template, tag and length
'4F' '0B' 'A0 00 00 06 68 00 00 00 01 NOVOFLEET AID
02 76'
'50' '09' " NOVOFLEET" Application label
(ASCII: '4E 4F 56 4F 46 4C 45
45 54')
'87' '01' '01' Application Priority Indicator
Table 7: NOVOFLEET Directory Entry Template

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.

DKV Card Specification1 | 15.11.2021 Page 7


Version 1.21
General Card requirements Fehler! Verweisquelle konnte nicht gefunden werden.

Tag Length Value Description


(in bytes)
'6F' '27' FCI, tag and length
'84' '0E' '32 50 41 59 2E 53 59 53 2E DF name of the DF_PPSE
44 44 46 30 31'
'A5' '15' FCI Proprietary Template
'BF0C' '12' FCI Issuer Discretionary Data
'61' '10' Directory Entry
'4F' '0B' 'A0 00 00 06 68 00 00 00 00 AID DKV
02 76'
'87' '01' '01' Application Priority Indicator
Table 8: FCI of the PPSE

2.4 Commands and Secure Messaging

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.

According to [CPA] section 18.1 Secure Messaging shall be performed as described in


section 9 of the CCD part of [EMV B2].

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:

All commands using Secure Messaging for integrity and authentication

• 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.

Page 8 DKV Card Specification1 | 15.11.2021


Version 1.21
General Card requirements

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].

Encryption of command data:

[CPA] section 18 describes the coding of the script commands and whether the command
data shall be enciphered.

Data enciphered for confidentiality shall be encapsulated with Tag '87'.

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].

DKV Card Specification1 | 15.11.2021 Page 9


Version 1.21
General Card requirements Fehler! Verweisquelle konnte nicht gefunden werden.

2.5 Defined SFI

2.5.1 PSE

SFI '01' is defined of the Directory Elementary File.

2.5.2 DKV Card Application

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.

Page 10 DKV Card Specification1 | 15.11.2021


Version 1.21

You might also like