Smart Card Application Standard Draft

Transcription

1 Smart Card Application Standard Draft

2 Contents 1 SCOPE DEFINITIONS / DOCUMENT CONVENTIONS KEY DATA ELEMENTS AND CONCEPTS STATIC CARD INFORMATION Card ID (CdID) Application Version CHALLENGE/RESPONSE VERIFICATION Challenge Response Verification CARD READING PROCESS APDU/RPDU SPECIFICATIONS ERROR HANDLING SELECT EVAPP COMMAND/RESPONSE APDU RPDU STATIC READ APPLICATION COMMAND/RESPONSE APDU RPDU SECURITY OPERATION COMMAND/RESPONSE APDU RPDU VERIFICATION REQUEST... 17

3 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 Charge Spot (CS) Card Charge Spot Operator (CS Operator) Card Issuer Verification EVAPP APDU RPDU Definition A power outlet to which a vehicle connects and which includes an ISO/IEC type A and B contactless smartcard card reader and a communication network connecting to the card issuer. An ISO/IEC type A or B contactless smartcard. 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. 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. The process of ensuring that a card is genuine and information was not retransmitted. The card application standardized in this document. This application would be issued a unique card application ID according to ISO/IEC 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. Short for response APDU.

4 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 ,999,999 Description Country code Numerical code of the card issuer Management Display Format According to ISO Allocated by national standardization bodies. Serial number assigned to the card Assigned and manage by a card issuer. Field Country Separator Operator Separator Serial Number Format/Value String. Decimal Number Example Transport Format IL Decimal Number Field Padding Country Operator Serial Number Format Example ASCII 00 00IL 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 2

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

6 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 format 3. 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

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

8 Card Reading Process The card read phase will have the following phases: Phase Request Response Description 1 ISO/IEC Polling 2 ISO/IEC Anti-Collision 3 ISO/IEC Activation According to the ISO/IEC principles. 4 Select EVAPP by AID 5 Read Static Record EVAPP FCI See 0 Card Static information See 0 6 Perform Security Operation Cryptogram See 0 7 ISO/IEC Teardown Close the connection as defined by ISO

9 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 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 SW1SW2 error code. Select EVAPP Command/Response APDU The Select Application command is detailed in the standard ISO/IEC 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: A 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:

10 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: F 1B XX XX XX 0008 XX XX XX XX A5 10 DF XX XX XX XX DF XX XX XX XX Static Read Application Command/Response APDU The Read Redcord command is detailed in the standard ISO/IEC 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

11 Issue: 1 Issue: Lc Issue: 0x00 Packet Example: 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: DF XX 0008 XX XX XX XX XX XX XX XX 0010 XX Security Operation Command/Response APDU The Perform Security Operation command is detailed in the standards ISO/IEC and ISO/IEC 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:

12 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: A E F0 1C 0008 DF XX XX XX XX 0010 XX XX XX XX DF YY YY YY YY DF 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: DF XX 0008 XX DF YY YY YY

13 0010 YY YY YY YY YY YY YY YY 0018 YY YY YY YY YY YY YY YY 0020 YY YY YY YY YY

14 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 time 4 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