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 EVAPPCOMMAND/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
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
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: P2 Issue: 0x00
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: Length Issue: APDU
Field Issue: Value
Issue: 1 Issue: CLA Issue: 0x00
Issue: 1 Issue: INS Issue: 0xB2
Issue: 1 Issue: P1 Issue: 0x01
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: Length Issue: Template Issue: Tag
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: Length Issue: APDU
Field 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: Issue: Issue: 0xDF 0x81 0x14
Issue: Issue: Issue: 0xDF 0x81 0x15
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: Length Issue: Template Issue: Tag
Issue: 2 Issue: 0x77 Issue:
Issue: 6 Issue: Issue: 0xDF
0x81 0x17
Issue: 28 Issue: Issue: 0xDF
0x81 0x16
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
