Suomen Tilaajavastuu Oy Version Published Page 1. Veronumero.fi

Transcription

1 Page 1 Suomen Tilaajavastuu Oy Veronumero.fi VALTTI SMART CARD Suomen Tilaajavastuu Oy Change history Date Changed by Change June 26, 2013 Suomen Tilaajavastuu Oy First version October 10, 2013 Suomen Tilaajavastuu Oy Security levels updated January 22, 2014 Suomen Tilaajavastuu Oy Card requirements adjusted February 20, Suomen Tilaajavastuu Oy Double chip added 2014 May 27, 2014 Lari Iso- Anttila English Version, Key handling corrected 10 March, 2015 Lari Iso- Anttila Terminal requirements updated

2 Page 2 Table of contents 1 Abbreviations and terminology Technical specification of ID card Card technology Identifying the card Managing the keys Creating a card- specific reading key Signing in on the card Keys to use with the card Mifare software directory Definition Security level definition Security level 0 definition Security level 0+ definition Security level 1 definition Security level 1+ definition ST card application and file Combination card Organisation s own RFID card s cooperation with the VALTTI card Terminal requirements ID card security Visual security Electronic identifiers Printing technology requirements Card provider requirements Further development plan Security levels + definition Managing the card keys Examples Identifying the card Identifying the card type Verifying the card version Authentication Requesting UID Requesting applications Authentication with an application ID Requesting file listing Reading selected file Registration and access list References... 18

3 Page 3 1 Abbreviations and terminology Abbreviation PrgD EV1 UID AID ST Stv T0 Security level 0 T1 Security level 1 T0+ Security level 0+ T1+ Security level 1+ RFID NFC Manufacture serial number Year of manufacture Week of manufacture RndID Application Explanation Programming device, card programming device MIFARE DESFire EV1 Unique card identifier Application ID Suomen Tilaajavastuu Oy The application on the EV1 card, the hex code of which is 0x Radio Frequency Identification Near Field Communication Batch number Production year Production week Random identifier Card s own application on the EV1 card/directory that contains the file created by ST

4 Page 4 2 Technical specification of ID card 2.1 Card technology The construction industry ID card s technology is based on the Mifare Desfire EV1. This technology makes it possible to use the card in several different services, for example, the card service of Suomen Tilaajavastuu Oy and the company s own system. The card uses commonly known encryption methods to secure air interface as well as the data recorded on the card. The selected card responds to the ISO/IEC Type- A definition. Each card allows 28 different applications to be saved and each application allows 32 files to be saved. The file size is defined when creating the file. This has a substantive impact on the number of files to be saved. The card offers a unique identifier and an optional random identifier against tapping. 2.2 Identifying the card The card identification procedure is described in the NXP document [2]. The Mifare products, Mifare Plus, Mifare Desfire and the SmartMX platform, follow the same standard as the Mifare Desfire EV1 card. Recognizing the card type is an important part of security. The Mifare Type Identification Procedure [3] and the MIFARE DESFire as Type 4 tag [2] documents include a description of how to identify the card (also in the Random ID mode). The card is identified using the model created by NXP to identify the EV1 card. The type of the ID card is identified as shown in the chart below. Chart 1 presents the procedure by which the Mifare Desfire EV1 card is identified. The procedure allows the separation of other cards and copies. It does not recognize emulation devices but these can be recognized as fakes visually. The card identification process starts by handling the Selective Acknowledge (SAK) response. The SAK value received from the response must be in binary format: 2nd bit is 0b 4th bit is 0b 5th bit is 0b 6th bit is 1b Next, the correct format of the final message is checked. Chart 1 (based on document [2]) Finally, the GetVersion Request is sent to the card. The response is an HW version, SW version, status on the card, UID if the Random ID has not been set, manufacture batch number, production week and production year. The card software must comply with format 1.x, otherwise the card is not of type Mifare Desfire EV1.

5 Page Managing the keys Using the card requires various keys, such as reading keys, registration keys and access keys. Below is a description of the use and purpose of the keys. Key Purpose User(s) Explanation Application key Application creation ST, partner companies Each partner has their own application key which functions as the card s master key. ST access key Card- specific reading key for the ST application Card- specific registration key for the ST application Authentication to ST application reading UID with Random ID. Can only read the ST application file and send it to the card service Used when creating the card ST, partner companies ST, partner companies ST The key is only revealed to partners. Diversified with data from the card Random Key 2.4 Creating a card- specific reading key Suomen Tilaajavastuu Oy s software (0x ) has its own access key used for authentication and meant for Suomen Tilaajavastuu Oy s application. After authentication the access control terminal (MD) can request the card for a true UID and other relevant information for creating a card- specific key. The card- specific key is used to read the file in Suomen Tilaajavastuu Oy s application. The card communication process is described later when defining the security levels. The card- specific reading key is created according to chart 2 using the CMAC method. The CMAC method is described in the NXP document MIFARE Symmetric key diversifications [4]. The final result of the operation is a unique key that only functions with one card. Chart 2 Versatile input for the card- specific key is a 16- byte string that consists of: Input Byte order Length Card UID Little- endian 7 bytes Card UID repeat Little- endian 7 bytes Fill 0xD8, 0x77 2 bytes

6 Page Signing in on the card The next chart presents the communication between the reader and the card in order to read the UID and the validation file that is on the card. The chart shows how to sign into the card in order to read its UID when the Random ID is on. The card allows reading of the data that is needed for the validation process of the ST card. In the chart the Reader sends a Select Application (0x765453) command to the Card and the card responds OK. If the response is different, the procedure must be interrupted and the user must be told that the application in question is not found on the card. After successfully selecting the application, identification on the card takes place by using the command Authenticate (AES, key 1, appauthkey). The response must be OK. Otherwise the procedure must be interrupted by informing the user of an identification failure. After an accepted identification, the card is read for its correct UID by using the command GetCardUID, to which the card responds with its correct UID. From here onwards the phases apply to security levels 1 and 1+. The data terminal device creates an appreadkey by using the UID, other card data, and the AppReadKeyBase. After the application reading key has been created, the data terminal signs into the card again by using the reading key. After sign- in, the data terminal device reads the data written for the application by using the command ReadData( 0, 0, 16). The returned authentication data is transmitted to the KorVa- service for authentication. KorVa- service will return OK message when card is genuine, if the validation fails then Korva- service returns error message. 2.6 Keys to use with the card Key number Key explanation 0 Master key, random Allows writing in the application. At the moment random and is forgotten after writing, so in practice the application is read- only. 1 File reading key, diversified by using the card UID and version details. Allows reading of the application files. 2 Authentication key, fixed Allows reading of the card UID and version details in order to form a reading key. Master Key Master key is provide separately

7 Page Mifare software directory Definition The Mifare Application Directory version 3 (MAD3) functional mode is described in the NXP document MIFARE Application Directory (MAD) [1]. The Mifare Desfire EV1 card uses the MAD3 definition. When creating AID, it must be noted that the AIDs starting with 0xF have been defined to belong to the Mifare Classic card series [1]. 2.8 Security level definition Because there will be cards by several producers based on this standard in the field, security levels must consider the unique needs of the companies. These unique needs include, among others, various third- party systems, e.g. identification at lunch cafeterias. Thus some cards may not use the Random ID feature by default, while other cards may have this setting on. All data terminal devices must support the Random ID feature whether it is in use on the card or not Security level 0 definition At security level 0 (T0) the card is handled as simply as possible in order to ensure quick communication between the card and the device. The access control terminal (data terminal) must read the card s UID on the card. The device must clarify the card s UID in order for the card to be used in different services, such as the Kulkuri service of Suomen Tilaajavastuu Oy or the card- holder company s own data system. At T0 the device must go through the following steps: 1. Detect card 2. Select card 3. Read card s true UID. At T0, the mandatory data to read on the card include the UID. It is also possible to read the UID from the communication between the card and the access control terminal Security level 0+ definition At security level 0+ (T0+) the access control terminal, i.e. the data terminal device, must be able to read the correct UID on the card, even if the card is set on random ID. The device must clarify the card s UID in order for the card to be used in different services, such as the Kulkuri service of Suomen Tilaajavastuu Oy or the card- holder company s own data system. In addition to this, the data terminal device must be able to read the card s true UID. Card identification must be implemented on the access control terminal because that will remove simple copies, such as RFID and NFC programmes coded in a smart phone. At T0 the device must go through the following steps: 1. Detect card 2. Select card 3. Read card s true UID. At T0+, the mandatory data to read on the card include card s type and the UID Security level 1 definition At security level 1 (T1), the access control terminal, i.e. the end terminal device, must recognize the card as type EV1 and authenticate it in the Suomen Tilaajavastuu Oy application on the card. The access control terminal reads the data necessary to create a card- specific reading key. The access control terminal creates a card- specific reading key to read the file included in the Suomen Tilaajavastuu Oy application. The file is located on the card in the index 0x00 of the Suomen Tilaajavastuu Oy application. The file read from the card is sent to be checked by Suomen

8 Page 8 Tilaajavastuu Oy s card service. The card service returns information about the correctness of the checked card. The data on the card can be handled and communicated with the STV card storage service in the device manufacturer s background service. This checking does not need to be done in the end terminal device. Card identification should preferably be done when taking the card into use. It is not obligatory to identify the card with the end terminal device every time it is used. At T1, the access control terminal must go through the following steps: 1. Detect card 2. Select card 3. Authenticate in the ST application on the card 4. Request the card UID and read the data necessary to create a card- specific reading key 5. Read the file included in the ST application index 0x00h 6. Send the file to the card service directly or through the manufacturer s background service in order to check its validity. 7. Handle response from the card service At T1, the data obligatory to read from the card include - Card type - Card UID - Manufacture serial number - Year of manufacture - Week of manufacture Security level 1+ definition The only difference between the definitions of security levels 1 and 1+ is that at security level 1+, the card is set to Random ID. 2.9 ST card application and file The AID of the application on the card is 0x This application has been defined with a file that is the application file in index 0x00. A unique file including a random number series is created for each card. This file is created in the ST card service. The file s length is 16 bytes Combination card By a combination card we mean a card that includes two or three separate RFID chips. The first chip must be a Mifare Desfire EV1 and designed for use with the VALTTI smart card. The other chip s model of operation is defined in the sections below. The Mifare Desfire EV1 s functionality with the VALTTI card has been described in previous sections Organisation s own RFID card s cooperation with the VALTTI card When attaching an organisation s own RFID card to the VALTTI card, the type of card to attach must be taken into consideration. The attached card can be anything, and the operation of the organisation s card must not disturb the operation of the VALTTI card. When the end terminal device used on the working site detects two cards, it must select the Mifare Desfire EV1 card. The Mifare Desfire EV 1 can be identified based on the type and model of the card. Another way to identify the card is by the length of its UID. However, if both cards use a 7- byte UID, identification must be made by card type and model. The end terminal device receives this information when the device detects the cards Terminal requirements Terminal device must read other tag- types as well as VALTTI- card (MIFARE DESFire EV1). Reader must read following types MIFARE DESFire EV1 and Miface Classic tag. Other MIFARE tag types are optional.

9 Page 9

10 Page 10 3 ID card security 3.1 Visual security VALTTI smart card VALTTI ID card Visual identifiers on the VALTTI smart card and ID card Name Company logo Tax code Employer Validity data Photograph Bar code (smart card only) RFID/NFC identifier (smart card only) Electronic Unicus identifier (smart card only) The information on the VALTTI smart card has been printed on a plastic card which easily displays the name, tax code, company, business ID, and period of validity. The smart card contains a bar code and an RFID so that it is also easy to read electronically. 3.2 Electronic identifiers A access control terminal or any other ID- card reading device creates a card- specific reading key that can be used for the ST application to read the file saved in the application. The card may contain company- specific software, files, access rights or PIN codes. This document does not express any opinion on amendments made by a third party. 3.3 Printing technology requirements Offset printing of the cards must be done so that the cards comply with the ISO/IEC 7810 standard [6]. Visual personalization must be applied by laser scribing. 3.4 Card provider requirements The facilities used to manufacture and identify the cards must comply with the following requirements: Facility classification 3 (zone 3, restricted zone) according to EU security rules [7] The provider must comply with the ISO standard [8] or other commonly accepted data security standard. The security arrangements of the facilities, equipment capacity, and production system must form their own zone, technically separated from other zones in terms of security. The facilities used to manufacture and identify the cards must not have visual contact from outside the facilities. Access to the production facilities must be via a single central entrance.

11 Page 11 Access must be implemented so that only authorized persons are allowed in the facilities. Access to production facilities must be verifiable later. The facilities must be guarded and monitored to a high degree 24h/day. The monitoring and security system must include recording camera surveillance, access control, break and entry protection, and alarms directed to a manned control room. The cards must be kept in a EURO V level safe or equivalent storage, such as a vault.

12 Page 12 4 Further development plan This chapter addresses further development areas with respect to the construction industry card standard. These areas are not included in the current version mainly because the field does not yet offer wide- scale hardware support for these technologies. 4.1 Security levels + definition For the security levels defined above (e.g. T0), the standard will cover reinforced versions (e.g. T0+). The most important change in the security levels + definition is the use of RndID. Putting RndID into use affects the traffic between the access control terminal and the card in such a way that the reading device must be authenticated for the Suomen Tilaajavastuu Oy application and ask for the card UID. RndID will be introduced in 2H Managing the card keys Another area for further development is standardized key management and key updates.

13 Page 13 5 Examples Sample events between the access control terminal and the card. These examples are for FEIG reader not to raw ISO protocol. 5.1 Identifying the card Inventory Request >> = CRC, see AN10787.pdf page 9, section 3.7 CRC Calculation =? = The Inventory command << C 8B 5A 52 0C F8 OK 69 F8 = CRC 80 2C 8B 5A 52 0C = UID or Random ID = OPT Info 0x00 - Random ID, 0x01 - Card s true UID = Card model = Card type =? = OK (so called status byte) 5.2 Identifying the card type Part 1 RATS i.e. checking SAK >> C 8B 5A 52 0C 04 A3 A5 A3 A5 = CRC 80 2C 8B 5A 52 0C = UID or Random ID = = = Driver used for the card? = The Select command Response for Answer To Select = RATS << F1 D2 OK F1 D2 = CRC = ATS = TL = SAK see AN11004.pdf page 7, section = b, Select Acknowledge = SAK = ATQA see AN10833.pdf page 9, table = = OK

14 Page Verifying the card version Part 2 GetVersion(Req) >> EE B0 EE B0 = CRC =? = The Inventory command GetVersion(Resp) << C 52 5A 8B 2C 80 BA CF B 67 OK Part 1: << = HW Storage Size 18 = = HW Version number is = OK Part 2: C 52 5A 8B 2C C 52 5A 8B 2C 80 = UID, 0 if Random ID is on = Protocol = SW Storage Size = = SW version minor number is = SW version major number is = Vendor ID, type, sub type Part 3: BA CF B 67 OK 2B 67 = CRC = Production year = Production week BA CF = Batch number If the process has proceeded thus far without an error and the SW major version is = 1, then it is Mifare Desfire EV Authentication Selected Application authentication >> FA DB 92 DB = CRC = Desfire Key Number, this information is sent to the reader = Reader key Index, this information is sent to the reader = Application ID = FA... = The Authenticate command Resp << 00 8C 36 OK 8C 36 = CRC = OK

15 Page Requesting UID GetUID() >> C 6C 9C 6C = CRC = = = Get UID Resp << C 52 5A 8B 2C 80 B0 CC OK B0 CC = CRC 04 0C 52 5A 8B 2C = AppID = OK 5.5 Requesting applications GetApplicationID() >> 6A C3 94 C3 = CRC =? =? 6A... = Get UID << B FA OK 9B FA = CRC = AppID = AppID = OK 5.6 Authentication with an application ID AuthWithAppId() >> FA EC 14 EC 14 = CRC = Reader Key index = DESFire Key number = Stv App Id FA = The Auth command << 00 8C 36 OK 8C 36 = CRC = OK

16 Page Requesting file listing >> 6F FA 29 FA = CRC = Stv App Id 6F... = The GetFileIDs command << OK 29 FA = CRC = File ID 0x01 (if application includes several files, STV includes only one file) = File ID 0x = OK 5.8 Reading selected file >> BD FF EC 6E EC 6E = CRC FF = Length of file to be read =? = File ID = DesFire Key Number = Reader Key Index = App ID BD = The Read Standard Data command File contents in hexadecimal format << F 6D 65 6E C A F F B 6F E 75 6D F E DD OK

17 Page 17 6 Registration and access list The access control terminal must be registered in the Suomen Tilaajavastuu Oy card service (card storage). The device manufacturer is responsible for registering the device and updating the access list. Registration means attaching the access control terminal to Suomen Tilaajavastuu Oy s marking data background system. The marking data, i.e. the Kulkuri service [5], handles the card s time stamping data.

18 Page 18 7 References [1] AN10787 MIFARE Application Directory (MAD) [2] AN11004 MIFARE DESFire as Type 4 tag [3] AN10833 MIFARE Type Identification Procedure [4] AN10922 MIFARE Symmetric key diversifications [5] Kulkuri service [6] ISO / IEC [7] Facilities classification according to EU security rules [8] ISO