Mifare Plus Card Commissioning Summary

Original address:: https://blog.csdn.net/wwwtovvv/article/details/9240783

Related articles

1, Mifare Plus card reading and writing module user manual----http://www.docin.com/p-1252890695.html

2, Mifare plus card reading and writing module----http://tieba.baidu.com/p/3968383719?traceid=

3, Mifare PLUS CPU card reader software green free version----http://dl.pconline.com.cn/download/547464.html

4, the difference between MIFARE plus-x and MIFARE plus-s----https://blog.csdn.net/zoomdy/article/details/51750286

5, Mifare Plus Introduction----https://wenku.baidu.com/view/3b65203e0912a21614792904.html

The default NXP released plus card is a L0 level uninitialized card, at which time the active operation behaves as a CPU card feature that supports Iso1443-4 (atqa:02, sak:20 uid:cd 03) When performing write-related AES Key and the data block are initialized and commit to enter the L1 security level, its active operation is represented by a M1S70 card characteristics (atqa:02, sak:18 uid:cd 03), but in essence it can still support E5, Perform rats success (which must also be supported, otherwise cannot perform switchL2 and SWITCH3 operations), when the L1 level is performed switchL2 authentication is converted to L2 level, after its active operation the return value is (atqa:02 sak:11, UID:CD + E5 03), the existing driver does not have this match SAK is the unknown card type, the L2 security level after performing SWITCH3 authentication card upgrade to L3 security level, after re-execution of the active operation after the return value (atqa:02, sak:20, Uid:cd 03).

Operations at the L1 and L2 levels are run in the active state (iso14443-3 layer), and when the card is at the L1 level, the M1-related interface can be fully executed, or the SL1 authentication can be performed first with AES M1 authentication, but there is no need to generate a session after performing AES SL1 authentication The key base and the M1 key calculation derive the new M1 key as the true M1 authentication key, using the M1 original key directly (this point differs from the L2 level).

At the L0 level, the return code of the PICC after execution is the same as the M1 card Ack/nak, the half-byte return code does not have CRC, so when the CRC check is turned on the CRC error occurs;

The AES SL1 authentication process at the L1 level, when executed correctly, returns a CRC return code and information, and when an error occurs (AES key error, RNDB decryption error, etc.) returns a nak that is consistent with the M1 card, with a half-byte without CRC error, and therefore CRC error when the CRC check is turned on.

The switchL2 instruction is executed at the iso14443-4 level, and after successful execution the PICC enters the L2 security level, at which time the switchL2 instruction returns two status bytes Cmd+bno+lencap+pcdcap2 when the first send 0x02, 0x09 0x09 can be understood as invalid block numbers, but 0x02 cannot understand them.

At the L2 level, as the manual says, AES authentication is required for M1 authentication, and the low 6 bytes of Session key base generated by AES are different from the actual block's M1 key or the true M1 block authentication key. The tested AES key type must be consistent with the M1 key type (that is, either a or all B types), otherwise the M1 authentication fails. When the AES and M1 key types and values of sector A are consistent with sector B, the access to sector B is consistent with the access to sector a after sector a authentication is passed, eliminating the need for Sector B authentication.

During the L2 security level debug Mifplauthinpro, when calling S_aescbcendecrypt, the add decryption fails because its input IV will overwrite IV upon completion of the addition and decryption, resulting in the next encryption and decryption of the IV change. The value of IV must be noted.

At the L2 security level, the AES key type must be kept consistent with the M1 key type using mandatory AES+M1 key authentication (i.e. AES TypeA KEY+M1 TypeA key or AES TypeB KEY+M1 TypeB key, such as AES TypeA KEY+M1 TYP EB key authentication fails even if the key is correct. ）

Complete the L2 level of debugging, can be repeated firstauth, and each Firstauth get the TI value is different, The correct followauth (Followauth IV based Firstauth authentication) will be performed after the correct Firstauth certification has been completed and TI has been obtained. Followauth can be repeated once the correct firstauth is performed. Since Firstauth and Followauth run in iso14443-4 mode, it is not necessary to re-seek card operation when any error occurs in the PICC or in iso14443-4 mode.

The Multiwriteblock and Multireadblock commands of the L2 security level only support read and write operations for most data blocks in the same sector. The L3 security level Readblock and WriteBlock commands support continuous data block reads and writes across sectors (in this sector only ...). ）

L3 Security-level Followauth operation get enc key and Mac key encryption using the IV vector of 0 instead of ti+w_ctr+r_ctr ...

In the iso14443-4 mode operation, the Firstauth operation must be performed as long as any error occurs.

Understanding of M1 Card Value related operations: The essence of the Restore command is to copy the incoming chunk value (which must be the wallet format) into a 16-byte transfer buffer inside the M1 card, and the essence of the transfer command is to M1 the transfer card inside The buffer value is copied into the incoming data block. The essence of the Increment command is to add the input wallet block value to the incoming increment value and copy it into the transfer buffer, so the transfer command must be called again to copy the transfer buffer value into the specified data block.