For Mifare DESFire EV1 support, we need to know when the user has called
mifare_desfire_select_application() after being authenticated and before
authenticated again.
The autohell hack sucks and should be fixed, but I was unable to find the magic
trick to prevent automake from building broken libtool rules which produce
warnings about portability :-/.
Mifare DESFire EV1 with authentication with AES or 3K3DES keys will require to
perform CMACing on each frame, even those with just a command. So it does not
break anything as of today, but would be a problem later on.
Some cryptographic operations are performed on the whole data frame and not
only the payload with Mifare DESFire EV1. The solution for now is not perfect,
(one new macro wrapping another big macro) but makes the code a bit easier to
read, and with the MIFARE_DESFIRE macro rewriting as a function (at some point
in the future), the whole should be bearable :-)
This have been done for consistency with other targets support, but
cryptographic operations with Mifare DESFire EV1 tags would require to swap
again this byte because MACing is performed on the following data (in this
order):
- Plain data
- Status
- Padding
Don't connect it to the build yet because the corresponding code in the library
has not been committed yet: I want to keep a track of modifications I do in the
VCS.
The 5th byte of Mifare DESFire being a "historical character" and being
user-tweakable for Mifare DESFire EV1, we should not use it when comparing the
ATS with our Mifare DESFire reference ATS to determine if a given tag is a
Mifare DESFire or not.
This feature was not used by the cards I initially used when coding the
, but is required for (at least some) Mifare DESFire EV1 to work.
IMPORTANT NOTE: The cards needing this block-number management to work out
break-down when mifare_desfire_format_picc() is performed on them. The ATR
change from 0x7577810280 to 0x757781028f and further communication alway result
in a timeout. At the time of committing, the reason is still unknown (bogus
cards, missed "Remarks" in the documentation, ...). Other commands seems to
not expose additional problems.
r565 was misinterpreted as a bug while it's a feature. Since it might be
inappropriate to do irreversible operations in an example, warn the user about
it.
