Because in some circumstances the crypto is skipped regardless of the
communication settings by the Mifare DESFire (e.g. when reading a file which is
writable with any key), do not abort if the crypto fail, and make it possible
to the user to catch such an event to fix his code accordingly.
Only display crypto diagnostic if compiled with debug support.
If the provided key is a 3K3DES key, authenticate in ISO mode. If the key is
an AES one, authenticate in AES mode. This sugar should help third party
applications to handle authentication in a more generic way.
ECOPYPASTETOOFAST | EBADLUCKITSVALID: The argument communication_settings is
not to be used to construct the parameters passed to the crypto functions
mifare_cryto_preprocess_data() & mifare_cryto_postprocess_data(), but only for
building the frame.
Please note that according to the NXP documentation of the Mifare DESFire EV1,
the mifare_desfire_authenticate_iso() function can be used using either 3DES or
3K3DES keys. The former has not been tested yet and is likely not to work. To
word it differently, this is a 3K3DES crypto support, not a ISO authentication
support...
The create_application() function has iso_ parameters for creating ISO
application but this mode is not available yet so the code is unused which
annoys the compiler when told to be somewhat strict.
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.
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
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.
After trying to tweak gindent so that it does not mess-up my ASCII art, give
and read the help of Vim to setup 'cinoptions' according to my needs
(cino=t0(0). This changeset reindent some bits that where not indented as they
should. A future commit will reindent the switch/case according to my (bad)
taste now that I have setup cindent correctly on my system (cino=t0(0:0).
nfc_initiator_transceive_dep_bytes() was removed, and
nfc_initiator_transceive_bytes() is now configured to behave like the one or
the other of the original functions. For details, see:
http://code.google.com/p/libnfc/source/detail?r=592
For the regression test-suite test_mifare_desfire, it's a ~11% performance
boost, with 206 cache hits out of 488 calls to
mifare_desfire_get_file_settings().
The check is already done by the PICC and we may not have access to the
required information to do the check from the library. Additionally, the
mifare_desfire_change_key() would require different keys to operate if we
detected an error, so no recovery of any kind is possible.
