MF2DL1000DA4SLASH02 datasheet(39/132 Pages) NXP

39 / 132 page

NXP Semiconductors

MF2DL(H)x0

MIFARE DESFire Light contactless application IC

MF2DL_H_x0

All information provided in this document is subject to legal disclaimers.

Product data sheet

Rev. 3.3 — 5 April 2019

COMPANY PUBLIC

430733

39 / 132

• configuring Value file with SetConfiguration

• enabling TMCLimit with ChangeFileSettings

• enabling exclusion of unauthenticated operations from Transaction MAC calculation

with ChangeFileSettings

This has the same effects as successful execution of AbortTransaction detailed below. A

new transaction is started.

Invalidating all previous write access to back up files within the currently selected

application is possible with the AbortTransaction command as defined in Section 11.9.2.

This command takes no parameter. The AbortTransaction invalidates all preceding write

access of the ongoing transaction to files with integrated backup mechanisms:

• Value file

• CyclicRecord file

If a Transaction MAC is calculated, see Section 10.3, the ongoing calculation is also

aborted and a new calculation is initiated.

The AbortTransaction does not affect the authentication status. After execution of this

command a new transaction is started.

The command is rejected if no application has been selected, i.e. the PICC or MF level

is currently selected. An error code is also returned if no write access has been done to

any of the backup file types and, in case the application is protected by the Transaction

MAC feature, no Transaction MAC calculation update has been done. This means no

command that is included in the Transaction MAC calculation has been executed, i.e. the

TMI is still the empty string. This is similar as for CommitTransaction.

The AbortTransaction requires CommMode.MAC if there is an active authentication.

It can be useful to cancel a transaction with the AbortTransaction command because

there is no need for re-authentication to the PICC or no need for a reset of the RF field

and a complete new ISO/IEC 14443 activation, which would have the same effect.

10.3 Transaction MAC

The Transaction MAC feature helps preventing e.g. fraudulent merchant attacks. It allows

a merchant operating a point-of-sale terminal to prove that the transactions he executed

with customers are genuine toward the card issuer’s or application provider’s backend.

This is done by letting the card generate a Transaction MAC over the transaction with

a key shared only by the card and the card issuer’s (or application provider’s) backend.

This key is called the AppTransactionMACKey. As this key will not be present in the

merchant’s terminal, it is not possible for the merchant to forge MACs toward the

backend. Note that this implies that (pre-)personalization of the card is done by the card

issuer and not at the merchant’s location.

MAC generation will also involve a Transaction MAC Counter maintained by the card,

which allows the backend to detect replay by the merchant. In addition this counter

allows the backend to detect missing transactions, which allows detecting fraud where

the merchant has increased the balance without reporting the transaction. Note that a

counter also allows for easier detection mechanisms of replay than keeping logs with

fingerprints of every transaction.

Fraud detection alone might not be sufficient if one cannot point to the fraudulent

merchant. Therefore, an additional configuration option requires that the merchant’s

terminal commits its identity during the transaction. This requires support of a SAM

MF2DL1000DA4/02 Datasheet(PDF) 39 Page - NXP Semiconductors

MF2DL1000DA4/02 Datasheet(HTML) 39 Page - NXP Semiconductors

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ...More

Datasheet Download

Link URL