logo资料库

Mifare Ultralight Features and Hintts(Mifare卡说明).pdf

第1页 / 共21页
第2页 / 共21页
第3页 / 共21页
第4页 / 共21页
第5页 / 共21页
第6页 / 共21页
第7页 / 共21页
第8页 / 共21页
资料共21页,剩余部分请下载后查看
1. Introduction
1.1 Purpose and Scope
1.2 How to use this document
1.3 Reference documents
2. Mifare( Ultralight application hints
2.1 Memory features
2.1.1 Using OTP memory for multiple ticketing
2.1.2 Transaction Speed
2.2 Proposed Security Mechanism
2.2.1 Confidentiality of stored Data
2.2.2 Integrity of stored Data
3. Using mifare( Ultralight in an existing mifare( Classic application
Differences: mifare( Classic - mifare( Ultralight
3.1 Transaction Command Flows
3.1.1 Transaction flow using Cascade Level 2
3.1.2 Transaction flow using Cascade Level 1 & Read Block 0
3.2 mifare( Ultralight and mifare( Reader
4. mifare( Ultralight Coil design hints
5. delivery types
6. Appendix
6.1 MF RC171 low level library extension: Cascade Anticollision
6.2 MF CM200 / CM500 low level library extension: Cascade Anticollison
6.3 Worked out example of proposed security mechanism
7. Legal information
7.1 Definitions
7.2 Disclaimers
7.3 Trademarks
8. Contents
AN 073120 mifare Ultralight Features and Hints Rev. 2.0 — 18 December 2006 Application note Document information Info Content Keywords Abstract Multiple ticketing, secured data storage, implementation hints This document presents features and hints for a secured and optimized application development using mifare® Ultralight cards.
NXP Semiconductors Revision history Rev Date Description AN 073120 mifare Ultralight Features and Hints 2.0 1.0 18.12.2006 15.05.2002 Security features (section 2.2) and example (annex 6.3) added First release Contact information For additional information, please visit: http://www.nxp.com For sales office addresses, please send an email to: salesaddresses@nxp.com Rev. 2.0 — 18 December 2006 © NXP B.V. 2006. All rights reserved. 2 of 21 Application note
NXP Semiconductors 1. Introduction AN 073120 mifare Ultralight Features and Hints 1.1 Purpose and Scope This application note is intended to describe the features of the mifare® Ultralight MF0ICU1, and the comparison to the mifare® Classic MF1ICS50. It addresses some security mechanisms which may be used to protect the data stored in the card and demonstrates the implementation of mifare® Ultralight into an existing mifare® Classic application and shows the necessary modification over the existing mifare® reader environment. The changes apply to all relevant Philips mifare® readers. 1.2 How to use this document Ultralight. This document contains a collection of hints and features that could be of interest for those, who plan to use the mifare® None of this information is intended to replace any of the relevant datasheets or design guides. 1.3 Reference documents 1. [M028630] mifare® Ultralight, Contact-less Single-trip Ticket IC MF0 IC U1, Functional Specification. 2. [M011731] mifare®, (Card) Coil Design Guide. 3. [sl070010] Temperature Management, Inlet Design. 4. [M057432] MIFARE® MF RC530 ISO14443A reader IC. 5. [M056633] MIFARE® MF RC531; ISO 14443 Reader IC. 6. [MC073933] MIFARE® and I Code CL RC632 Multiple protocol contact less reader IC. 7. [ISO/IEC 14443-3] Identification cards- Contactless integrated circuit(s) cards- proximity cards- Part 3: Initialization and anticollision. 8. [FIPS46-3] Data Encryption Standard. 9. [ISO/IEC 9797-1] Information technology Security techniques Message Authentication Codes. Application note Rev. 2.0 — 18 December 2006 © NXP B.V. 2006. All rights reserved. 3 of 21
NXP Semiconductors 2. Mifare® Ultralight application hints AN 073120 mifare Ultralight Features and Hints 2.1 Memory features In addition to the user memory area the mifare® Ultralight offers the features of an OTP1 area and lock bytes to lock the OTP and user area. The usages of LOCK bits are described in [M028630]. A mifare® Ultralight dedicated 4-byte WRITE-command provides a high transaction speed. All the add-on features are dedicated to support special application functionality e.g. ticketing. 2.1.1 Using OTP memory for multiple ticketing Initialize: Write “FFFFFFF0 hex” The 4 OTP bytes, which are pre-set to “0” at the delivery, can be set to “1” only once. This gives the possibility to interpret them as an irreversible counter. Therefore, the number of “1” bits in Page 3 can be considered as counter value. This counter can be incremented by changing a bit from “0” to”1”. The counter cannot be decremented due to a “1” bit of Page 3 cannot be cleared. In this case this 4-byte offers a number of 32 states that could be used to allow a certain number of passing turn-styles. Example: An example of a four rides ticket is shown in figure 1. For this application a ticket issuing the OTP memory of the mifare® Ultralight has to be pre-set to “FFFFFFF0hex”. Page 3: Byte 12 Page 3: Byte 12 1111 Page 3: Byte 12 Page 3: Byte 12 Page 3: Byte 12 First use Last use 2nd use 14 1111 15 1111 0111 13 1111 1111 15 1111 13 1111 1111 14 1111 15 1111 0011 14 1111 14 1111 1111 15 1111 13 1111 1111 13 1111 1111 3rd use 1111 0001 1111 1111 1111 1111 1111 1111 13 1111 1111 15 1111 1111 1111 1111 1111 0000 1111 1111 14 1111 1111 Figure 1: Example of a four rides ticket Application note 1 One Time Programming Rev. 2.0 — 18 December 2006 © NXP B.V. 2006. All rights reserved. 4 of 21
NXP Semiconductors AN 073120 mifare Ultralight Features and Hints For every access, the 4-byte OTP (page 3) has to be checked and updated (as shown in Figure 2) to ensure the validity of the tickets. Using the same command flow the counter might be extended to a number of 31 times just by changing the initial memory content. E.g. “FFFFFC00hex” or “FC00FC00hex” might be used for a 10 times counter initial value, or “FFF00000hex” for a 20 times counter initial value, which has to be written into the OTP memory while issuing the ticket. Application rotates left Page 3 by one bit Write new value back into page 3 Grant Access =“FFFFFFFFhex”? Refuse entry → new ticket yes Read Page 3 no Figure 2: Ticket Counter Command flow Remark: With the initial value “00000000hex” for 32 times counter, the rotate left at the very first access check after selling the ticket has to be exchanged into another initial WRITE command. Application note Rev. 2.0 — 18 December 2006 © NXP B.V. 2006. All rights reserved. 5 of 21
NXP Semiconductors AN 073120 mifare Ultralight Features and Hints 2.1.2 Transaction Speed Although the mifare® Ultralight offers the 16-byte Compatibility Write command to be compatible with the mifare® Classic environment, the use of the 4 byte Write command is recommended, transaction. The Write saves approximately 20% of the transaction time2 compared to the Compatibility Write, as can be seen in Table 1. the application requires a fast if Command REQA Anticollision level 1 + 2 & Select Read Write Compatibility Write Halt ∑ (approximately) 4 pages 0.4 ms 3.7 ms 2.0 ms 12 pages 0.4 ms 3.7 ms 6.0 ms 18.7 ms 56 ms 24.0 ms 72 ms 0.5 ms 0.5 ms 25.3 ms 30.6 ms 66.6 ms 82.6 ms The transaction time2 as shown in Table 1 counts the time needed for Table 1: Transaction time the communication from the reader to the mifare® Ultralight, the response time of the mifare® Ultralight and the communication from the mifare® Ultralight back to the reader. • • • 2 This doesn’t include the time requires the host computer for the application itself (e.g. calculating & checking ticket values, displaying results, opening gates, etc.). Application note Rev. 2.0 — 18 December 2006 © NXP B.V. 2006. All rights reserved. 6 of 21
NXP Semiconductors AN 073120 mifare Ultralight Features and Hints 2.2 Proposed Security Mechanism Mifare® Ultralight has been designed to support the faster application with the cheapest solution. Therefore it does not address any security feature except the unique identity (UID). From the application point of view this means, no authentication has to be performed and no key is needed. Performing a mifare® authentication generates an error, and the mifare® Ultralight goes back to the Idle (or Halt) state. But if requires, smarter secured application using mifare® Ultralight can be created using an intelligent reader with the respective application software. A lot of cryptographic technologies are available to assist you. One successfully implemented approach is demonstrated in the following sections. This approach uses a 16-byte Master key (Mk), which is used to add the confidentiality and integrity of the storage data. 2.2.1 Confidentiality of stored Data As the mifare® Ultralight pages can be read without any authentication, anyone can read the pages using any standard reader. But if the stored data is encrypted with a secured key then these are just some bytes to one who does not have the secret key and information regarding the encryption method. Therefore by storing the encrypted data in mifare® Ultralight memory, one can add the confidentiality to the data itself. As an example a 3-DES [FIPS46-3] may be used for this encryption. Data stored = f ( key , data origin )UID , 7-byte UID of the mifare® Ultralight has to be incorporated in the security system to confirm the uniqueness of the tickets and a 16-byte Master Key (Mk) has to be defined by the application provider. To decrease the threat on the Master key (Mk), for each card, a Card key (Ck) is derived from the Master Key (Mk) using the well known key diversification. The steps to be followed are: • Expand the 7-byte UID,( 56 (7x8) bits (b55 - b0)) to 64 bits to get 8-byte extended UID (UIDe) by adding the odd parity (p) in the least significant bit position for each 7 bits as shown in table 2: (Byte0 to Byte7, 8 bytes are the bytes of UIDe whereas b0-b55 are the bits of original UID) p7b55b54b53b52b51b50b49p7 p6b48b47b46b45b44b43b42p6 p5b41b40b39b38b37b36b35p5 ……… ……… Byte7 Byte6 Byte5 Byte1 Table 2: Expanding of the UID to get UIDe p1b13b12b11b10b9b8b7p1 p0b6b5b4b3b2b1b0p0 Byte0 • Derive the Card key (Ck) as follows: Mk DES Encryption using UIDe as key Kc • Encrypt the plain data using the Card Key (Ck) in CBC (send) mode. • Use standard initial vector (IV) of all ‘00’s, IV= “0000000000000000h” • As DES works with 8-byte block wise, organize the data in multiple of 8 by adding the standard padding [ISO/IEC 9797-1] with all zeros ‘00h’. As example (‘xx’ is the data bytes ): Rev. 2.0 — 18 December 2006 © NXP B.V. 2006. All rights reserved. 7 of 21 Application note
NXP Semiconductors AN 073120 mifare Ultralight Features and Hints 2 padding bytes: xx xx xx xx xx xx 00 00 7 padding bytes: xx 00 00 00 00 00 00 00 The complete scheme is shown in the following figures (figure 3 & figure 4): Plain data Plain data IV = f(UID) IV = f(UID) Ck MK MK P0 P0 P1 Pm P1 Pm Byte 0...7 Byte 8...15 Byte n-7 .. n Byte 0...7 Byte 8...15 Byte n-7 .. n 3DES 3DES Enciphering Enciphering 3DES 3DES Enciphering Enciphering 3DES 3DES Enciphering Enciphering Ciphered data Byte 0...7 Byte 8...15 Byte n-7 .. n Ciphered data Byte 0...7 Byte 8...15 Byte n-7 .. n C0 C0 C1 Cm C1 Cm m = (n+1)/8 -1; where m and n are integer p = plain 8-byte block C = ciphered 8-byte block Figure 3: Data encryption scheme C1 Cm C1 Cm byte 8 …15 byte 8 …15 byte n-7…n byte n-7…n C0 C0 Ciphered data Ciphered data byte 0...7 byte 0...7 Therefore the data has to be decrypted after reading it from the card. 3DES 3DES Deciphering Deciphering 3DES 3DES Deciphering Deciphering IV = f(UID) IV = f(UID) MK MK Ck P0 P0 P1 Pm P1 Pm 3DES 3DES Deciphering Deciphering Plain data Plain data byte 0...7 byte 8...15 byte n-7 …n byte 0...7 byte 8...15 byte n-7 …n Application note Rev. 2.0 — 18 December 2006 © NXP B.V. 2006. All rights reserved. 8 of 21
分享到:
收藏