69_215_NP

Smart Card Application Standard

Draft

Contents

1 SCOPE ..................................................................................................................... 6

1.1 DEFINITIONS / DOCUMENT CONVENTIONS ............................................................ 6

2 KEY DATA ELEMENTS AND CONCEPTS ...................................................... 7

2.1 STATIC CARD INFORMATION ................................................................................. 7

2.1.1 Card ID (CdID) ........................................................................................... 7

2.1.2 Application Version ..................................................................................... 8

2.2 CHALLENGE/RESPONSE VERIFICATION ................................................................. 8

2.2.1 Challenge ..................................................................................................... 9

2.2.2 Response .................................................................................................... 10

2.2.3 Verification ................................................................................................ 10

3 CARD READING PROCESS .............................................................................. 11

4 APDU/RPDU SPECIFICATIONS ...................................................................... 12

4.1 ERROR HANDLING .............................................................................................. 12

4.2 SELECT EVAPP COMMAND/RESPONSE .............................................................. 12

4.2.1 APDU ........................................................................................................ 12

4.2.2 RPDU ........................................................................................................ 12

4.3 STATIC READ APPLICATION COMMAND/RESPONSE ............................................ 13

4.3.1 APDU ........................................................................................................ 13

4.3.2 RPDU ........................................................................................................ 14

4.4 SECURITY OPERATION COMMAND/RESPONSE .................................................... 14

4.4.1 APDU ........................................................................................................ 14

4.4.2 RPDU ........................................................................................................ 15

5 VERIFICATION REQUEST .............................................................................. 17

Scope

This document standardizes a contactless smartcard EV application (EVAPP) to ensure that an EV charging card can be read and verified. The document introduces key concepts and then specifies the actual messages between the smart card and the CS.

Definitions / Document Conventions

Term Definition

Charge Spot (CS) A power outlet to which a vehicle connects and which includes an ISO/IEC 14443 type A and B contactless smartcard card reader and a communication network connecting to the card issuer.

Card An ISO/IEC 14443 type A or B contactless smartcard.

Charge Spot Operator (CS Operator)

The organization operating the CS. A CS would normally connect to a control center operated by the CS operator and only through it to the card issuer systems.

Card Issuer The organization that issued the card to the customer and can verify its authenticity. This organization would normally have some contact in place with both the customer and the CS operator to facilitate the use of electricity by the customer at the CS.

Verification The process of ensuring that a card is genuine and information was not retransmitted.

EVAPP The card application standardized in this document. This application would be issued a unique card application ID according to ISO/IEC 7816-5.

APDU APDU stands for “Application Protocol Data Unit”. A communication unit between a smartcard reader and a smartcard. The structure of an APDU is defined by the ISO/IEC 7816 standards.

RPDU Short for response APDU.

Key Data Elements and Concepts

Static card information

The following information should be available on the card, transmitted to the CS and forwarded to the acquirer during a card read.

Card ID (CdID)

The card ID is send by the card both in clear text and signed as part of the cryptogram for verification purposes. The card ID is used by the CS or CS operator to route the verification request to the card acquirer.

Content

Field Country Operator Card Number Length/Range 2 characters 1-100 1-999,999,999 Description Country code Numerical code of

the card issuer Serial number assigned to the card

Management According to ISO 31662

Allocated by national standardization bodies.

Assigned and manage by a card issuer.

Display Format

Field Country Separator Operator Separator Serial Number

Format/Value String “.” Decimal Number

“.” Decimal Number

Example IL.1.14534

Transport Format

Field Padding Country Operator Serial Number Format ASCII

“00” 2 character ASCII string

Decimal number left padded with zero to fill 3 characters ASCII string

Decimal number left padded with zero to fill 9 characters ASCII string

Example 00IL001000014534

2 http://www.iso.org/iso/english_country_names_and_code_elements

http://www.iso.org/iso/english_country_names_and_code_elements

Application Version

• CdVer and CdEnc are 4 bytes unsigned integers written to the card at issuing or pre-personalization and should not be writable from the outside afterwards.

• CdVer and CdEnc are sent by the card with each use and relayed to the card acquirer.

• Their use is determined by the card issued and acquirer and is opaque to CS and CS operator. These fields enable flexibility in issuing cards which enable updates while keeping compatibility with older cards. Two use cases already identified are:

o Changing a master key: a different CdVer value could be used to indicated a different master key in case of a compromise or key distribution.

o Changing encryption algorithms: if the card is capable of more advanced algorithms, or if a flaw is found in the response generation function, CdEnc can indicate a different encryption suite.

Challenge/Response Verification

Card verification is performed between the CS, card and the card issuer using a challenge/response mechanism and the following flow. Note that the actual implementation of the response generation is internal to the card and issuer system and not part of this standard.

Challenge

The following fields should be sent by the CS to the card as a challenge: TransTime Unsigned Integer 8 bytes Current time in Unix time format3. RdRand Unsigned Integer 4 bytes A random number CsIDHash Unsigned Integer 4 bytes

See section 0 for more information

3 For details on Unix time refer to http://en.wikipedia.org/wiki/Unix_time

http://en.wikipedia.org/wiki/Unix_time

CSID.

Response

The following fields should be sent by the card to the CS as a response: Cryptogram Unsigned Integer 24 bytes The card response to the challenge. CdCount Unsigned Integer 2 bytes The card may keep a 16 bit internal

card register that is incremented each time the card provided a challenge response to a reader. The counter enables a verification server to ensure that a response is not recorded and retransmitted intentionally.

Note that while the card has this feature the verification server does not have to use and can rely on the alternate time based method

Verification

As noted the details of the verification process are internal to the card issuer implementation. However, the system allows for the following mechanisms to ensure that information cannot be copied of replayed:

• The card ID may be signed by the card.

• The transaction time may be signed by the card.

• CdCount may be implemented and signed by the card to ensure it is an ever increasing number.

• The device ID of the charge spot is signed by the card. The issuer may alternate means of validating the ID, such as ensuring the charge requests for a device are received only from the partner to which this device belongs.

Card Reading Process

The card read phase will have the following phases:

Phase Request Response Description

1 ISO/IEC 14443 Polling

According to the ISO/IEC 14443 principles.

2 ISO/IEC 14443 Anti-Collision

3 ISO/IEC 14443 Activation

4 Select EVAPP by AID

EVAPP FCI See 0

5 Read Static Record

Card Static information

See 0

6 Perform Security Operation

Cryptogram See 0

7 ISO/IEC 14443 Teardown Close the connection as defined by ISO 14443.

APDU/RPDU specifications

Error Handling

• Any other coding of the any of the APDU below will be answered by the card using an ISO/IEC 7816-4 SW1SW2 that define a relevant error code.

• A multi-application reader might send to the card other commands during the application selection phase not listed below, the card will response to any other commands not listed below using an ISO/IEC 7816-4 SW1SW2 error code.

Select EVAPP Command/Response

APDU

The Select Application command is detailed in the standard ISO/IEC 7816-4. The coding of the select EVAPP APDU will be according to the following:

Issue: Length Issue: APDU Field

Issue: Value

Issue: 1 Issue: CLA Issue: 0x00

Issue: 1 Issue: INS Issue: 0xA4

Issue: 1 Issue: P1 Issue: 0x04


Issue: 1 Issue: Lc Issue: 0x07

Issue: 7 Issue: Data Issue: EVAPP

Issue: 1 Issue: Le Issue: 0x00

Packet Example: 0000 02 00 A4 04 00 07 XX XX

0008 XX XX XX XX XX 00

RPDU

The above Select application APDU will be responded by the card with the following RPDU:

Issue: Length Issue: Template Issue: Tag

Issue: 2 Issue: 0x6F Issue:

Issue: 8 Issue: Issue: 0x84

Issue: 3 Issue: Issue: 0xA5

Issue: 8 Issue: Issue:

Issue: 8 Issue: Issue:

Packet Example: 0000 02 6F 1B 84 07 XX XX XX

0008 XX XX XX XX A5 10 DF 81

0010 10 04 XX XX XX XX DF 81

0018 11 04 XX XX XX XX 90 00

Static Read Application Command/Response

APDU

The Read Redcord command is detailed in the standard ISO/IEC 7816-4. The coding of the APDU of read record command in the EVAPP will be according to the following:


Issue: Value

Issue: 1 Issue: CLA Issue: 0x00

Issue: 1 Issue: INS Issue: 0xB2


Issue: 1 Issue: P2 Issue: 0x0C

Issue: 1 Issue: Lc Issue: 0x00

Packet Example: 0000 03 00 B2 01 0C

RPDU

The above Select application APDU will be responded by the card with the following RPDU:


Issue: 2 Issue: 0x70 Issue:

Issue: 13 Issue: Issue: 0xDF 0x81 0x12

Packet Example:

0000 03 70 14 DF 81 12 10 XX

0008 XX XX XX XX XX XX XX XX

0010 XX 90 00

Security Operation Command/Response

APDU

The Perform Security Operation command is detailed in the standards ISO/IEC 7816-4 and ISO/IEC 7816-8. The APDU of the perform security operation in the EVAPP APDU will be according to the following:


Issue: Template/Tag

Issue: 1 Issue: CLA Issue:

Issue: 1 Issue: INS Issue:

Issue: 1 Issue: P1 Issue:

Issue: 1 Issue: P2 Issue:

Issue: 1 Issue: Lc Issue:

Issue: 7 Issue: Data Issue: 0xF0

Issue: Issue: Issue: 0xDF 0x81 0x13



Issue: 1 Issue: Le Issue:

Packet Example:

0000 02 80 2A 82 80 1E F0 1C

0008 DF 81 13 08 XX XX XX XX

0010 XX XX XX XX DF 81 14 04

0018 YY YY YY YY DF 81 15 04

0020 TT TT TT TT 00

RPDU

The above security operation APDU will be responded by the card with the following RPDU:


Issue: 2 Issue: 0x77 Issue:



Packet Example: 0000 02 77 22 DF 81 17 02 XX

0008 XX DF 81 16 18 YY YY YY

0010 YY YY YY YY YY YY YY YY

0018 YY YY YY YY YY YY YY YY

0020 YY YY YY YY YY

Verification Request

Based on information the charge spot gathers during card read, it creates a verification block. The verification block is the data unit sent across the network from the charge spot to the card issuer and used to verify the authenticity of the card.

The structure of the verification block is: Field Format Length Description CdVer Unsigned integer 4 bytes Application version used by the

card as sent by the card. CdEnc Unsigned integer 4 bytes Encryption algorithm used by the

card as sent by the card. CdID Fixed length

string 16 bytes The Card ID in transport format

(see 0). CdCryptogram Unsigned Integer 24 bytes The response provided by the card

for the challenge as sent by the card.

CdCount Unsigned Integer 2 bytes The card use counter as received in the response.

TransTime Unsigned Integer 8 bytes Challenge time in Unix time4 format

RdRand Unsigned Integer 4 bytes Challenge random number CsID Null terminated

string 64 bytes The charging device ID from

which the CDevHash was derived.

4 For details on Unix time refer to http://en.wikipedia.org/wiki/Unix_time

http://en.wikipedia.org/wiki/Unix_time

69_215_NP

Documents

Transcript of 69_215_NP