ChameleonMini
ChameleonMini copied to clipboard
emsec
Support for MIFARE DESFire
I would very much like to see Chameleon supporting emulation of DESFire cards. I reckon this was already implemented according to the WISSEC paper, but is not shred with general public. Any plans on putting it on github?
Me to for MIFARE DESFire EV1 and MIFARE DESFire EV2 versions
On 13 October 2016 at 16:04, Ing. Radomír Polách [email protected] wrote:
I second this. MIFARE DESFire is a must.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/31#issuecomment-253540424, or mute the thread https://github.com/notifications/unsubscribe-auth/AC90mE5Tr35IfzaoBNtkZoKTbtVftMTmks5qzkhlgaJpZM4KVkDW .
I agree - however DESFire has a very complex protocol (three different modes of communication to start with, many functions, ...) -> we will likely start with a subset (in the WISSEC paper, it was mainly just authentication). If anyone wants to further contribute here pls contact us (or do it and send us a pull request for the complete DESFire emulation :) )
Thanks David! If I can have the authentication code, I think I can hard code the file system of a target card. Please do see if you can include the DESFire authentication in the code.
FYI, this is what's lying around the 'nets: http://www.ti.com.cn/cn/lit/an/sloa213/sloa213.pdf Quite nice for TI guys to provide everyone with such a nice reference implementation... ;-)
By the way, any suggestions for a good (= compliant, stable, documented APIs) reader for these cards? Will have to test with something, right? AFAIK, proxmark3 does not support DESFire cards, and that's the only one "reader" I have.
libfreefare has DESFire support, so it works with any libnfc-compliant reader. The libfreefare code could also be useful as a reference how the reader side works. However there are some quirks in the freefare code, e.g., it forces the DESFire to speak at 424 kBit/s, which is not supported on the Chameleon currently. So you'd have to patch the respective code parts to use 106 kBit/s. libfreefare uses the APDU-wrapped mode by default, ie puts the native DESFire commands into an APDU (Note: there is also an APDU mode with ISO7816 commands, I think this is used rather infrequently in reality though). I think a DESFire emulation should support at least the native commands and the APDU-wrapped ones. So there probably have to be RX/TX functions that handle this transparently.
Since everyone is really looking forward to having support for DESFire in Chameleon, I think it is OK to ask for some help. :-) Could anyone who has the actual cards do a few captures of PDU traffic between cards and readers, for reference? Selecting the card, authenticating, selecting an app, reading a file... that kind of stuff. Including the 14443-4 headers please. Bonus points for full captures of 14443-4 and 7816 exchanges! Thanks!
FWIW, I think I have implemented ISO 14443-4 layer and stuff below it, so I'm working on implementing DESFire commands now. Not sure at which point it will be ready for testing, but I am confident we'll have something before mid-November.
Maybe the captures here help:
http://adamsblog.aperturelabs.com/2013/02/atmel-sam7xc-crypto-co-processor-key.html
Otherwise give us a few days and we'll get/find something.
@dev-zzo thanks for your effort on the DESFire stuff. afaik pm3 has some DESFire support...
If you still need captures of DESFire card communication, I could contribute. I have some DESFire + DESFire EV1 + DESFire EV2 cards. I think it would be handy to have at least the common command set, that all DESFire cards support. (native commands and the APDU-wrapped)
@david-oswald Thanks for the link, I will go through it ASAP!
@martinbeier Would be awesome if you could play with them cards and share PDU traces. As for the command set, I am currently at the basic DESFire level; I believe EV1 and EV2 are supersets but I don't have docs to back that.
@dev-zzo I can confirm your assumption, DESFire EV1 and EV2 are fully backward compatible
And we have the first contact, ladies and gentlemen.
https://gist.github.com/dev-zzo/77e1365d40b0a70f8d33e988412afcb3
Now to find a reader that would issue actual commands. :)
@skuep The code is public at https://github.com/dev-zzo/ChameleonMini/tree/desfire
That looks great :smile:. I will gladly give you some support in two weeks @dev-zzo once I receive the ChameleonMini (I know well the protocol as I implemented all DESFire EV1 communication into LibLogicalAccess library, hope I can be from some help) and free time. If you haven't finished it yet so you're fast haha.
This is very impressive, we really like your work and look forward to any progress you make!
The current implementation will be able to support emulation of EV0 cards completely, and EV1 cards to some extent. Currently, I don't have insight into how key material is managed for EV1/EV2 cards, specifically the nuances of setting the key type... but I will find out eventually. >:-)
For EV0, the remaining parts are the actual FS interactions (values/record files, read/write operations, transactions). Authentication, key material management, and application management should be ready for testing; if anyone is willing to test and debug this please do so.
Can't compile version in your repo, I am getting:
avr-gcc -c -pipe -gdwarf-2 -g2 -mmcu=atxmega128a4u -fshort-enums -fno-inline-small-functions -fpack-struct -Wall -fno-strict-aliasing -funsigned-char -funsigned-bitfields -ffunction-sections -I. -I../LUFA/.. -DARCH=ARCH_XMEGA -DBOARD=BOARD_NONE -DF_USB=48000000UL -DF_CPU=27120000UL -mrelax -fno-jump-tables -x c -Os -std=gnu99 -Wstrict-prototypes -Wall -DUSE_LUFA_CONFIG_HEADER -DFLASH_DATA_ADDR=0x10000 -DFLASH_DATA_SIZE=0x10000 -DSPM_HELPER_ADDR=0x21FE0 -DBUILD_DATE=161025 -DCOMMIT_ID=\"4032cd8\" -DCONFIG_MF_CLASSIC_1K_SUPPORT -DCONFIG_MF_CLASSIC_1K_7B_SUPPORT -DCONFIG_MF_CLASSIC_4K_SUPPORT -DCONFIG_MF_CLASSIC_4K_7B_SUPPORT -DCONFIG_MF_ULTRALIGHT_SUPPORT -DCONFIG_MF_DESFIRE_SUPPORT -DCONFIG_ISO14443A_SNIFF_SUPPORT -DCONFIG_ISO14443A_READER_SUPPORT -DSUPPORT_MF_CLASSIC_MAGIC_MODE -DSUPPORT_FIRMWARE_UPGRADE -DDEFAULT_CONFIGURATION=CONFIG_NONE -DDEFAULT_RBUTTON_ACTION=BUTTON_ACTION_CYCLE_SETTINGS -DDEFAULT_LBUTTON_ACTION=BUTTON_ACTION_RECALL_MEM -DBUTTON_SETTING_GLOBAL -DDEFAULT_RED_LED_ACTION=LED_SETTING_CHANGE -DDEFAULT_GREEN_LED_ACTION=LED_POWERED -DLED_SETTING_GLOBAL -DDEFAULT_LOG_MODE=LOG_MODE_OFF -DLOG_SETTING_GLOBAL -DDEFAULT_SETTING=SETTINGS_FIRST -DDEFAULT_PENDING_TASK_TIMEOUT=10 -DENABLE_EEPROM_SETTINGS -MMD -MP -MF Bin/Commands.d Terminal/Commands.c -o Bin/Commands.o
Terminal/Commands.c: In function ‘CommandGetVersion’:
Terminal/Commands.c:24:3: error: invalid initializer
snprintf_P(OutParam, TERMINAL_BUFFER_SIZE, PSTR(
^
../LUFA/Build/lufa_build.mk:294: recipe for target 'Bin/Commands.o' failed
make: *** [Bin/Commands.o] Error 1
@dev-zzo It looks like you have your old Makefile fix for compiling under Windows, which breaks up compiling under linux.
@geo-rg @exander77 I have rebased my branch to master's HEAD, it should be OK now.
I think it's best if you create issues in my fork for any problems you might discover. :-)
I don't see issue section on your repository, do you have it enabled? But it compiles fine now. I will try DESFIRE emulation and will report back.
I am looking at ATS values, the emulation gives me 7500810200, normal Desfire cards gives me 7577810280, same as here: http://nfc-tools.org/index.php?title=ISO14443A
@exander77: second byte is the "speed" byte and as the current emulation only supports the slowest speed, @dev-zzo prefers to indicate to the reader to not try higher speeds. Last byte changes too as it's a checksum.
I just tested emulation on some doors, I had success with some doors, but not with all, maybe related to the speed?
@exander77 From what I know, the 2nd byte in ATS reports which comm speeds the card supports, as correctly noted by @doegox ; as Chameleon right now doesn't support anything faster than the basic 106k/s, that's what is hardcoded in my emulation. If the reader tries to use higher speed then it won't work anyway, so there is no big point in reporting faster speeds. The last byte reportedly is unused and can be set to anything, but I will set ti to 80 to better mimic the original hardware.
@exander77 please capture the exchange for the ones that didn't work; you can use proxmark3 for that.
For those trying things and seeing bugs: use the built-in logging facility to save traffic for future analysis. Before presenting the card, use LOGMODE=MEMORY to save the data, then use LOGDOWNLOAD to get it from the card to your box. Use chamlog to read the trace. This can provide the insight needed to fix things! Thanks :-)
Alright, we're battling with auth code now... I am not exactly sure what the problem is, though. If I understand the D40 algorithm correctly, then on the first step, the card sends E(RndB) without using CBC at all (the IV is not updated). On step 2, the reader sends E(RndA|RndB') using CBC with zero IV -- and this is the only mention of CBC in the whole chapter on auth in the doc. On step 3, the card sends E(RndA'), again without using CBC. This does align with the example here: https://ridrix.wordpress.com/2009/09/19/mifare-desfire-communication-example/ -- if you do each step manually data agrees well (assuming the key of all zeros).
The problem is, libfreefare doesn't agree with this flow: https://github.com/nfc-tools/libfreefare/blob/master/libfreefare/mifare_desfire.c#L366 seems to use CBC all the way through the three steps.
I have come up with a method to test whether at least parts of crypto work as expected... We can easily figure out what RndB is since we know the key the card uses and can decipher the value from the data being sent over the wire. We can also figure out RndB' from what the reader sends; since CBC is used in send mode, we can use the first block E(RndA) as the IV and get the plaintext for 2nd block easily as well. So we can verify RndB being handled correctly at all times if we know the key; additionally, this does not depend on whether CBC is used throughout or only on step 2. This seems to work on the data in Ridrix's blog page but not on e.g. Adam's blog and not in tests with a reader we have. Why? No idea whatsoever. Any insights from you guys?
All steps are with CBC, ridrix told it in a comment Beware older and newer Desfire don't use the same auth protocol: older are using the trick described in ridrix comment and newer are using a regular CBC as you may expect. cf https://github.com/nfc-tools/libfreefare/blob/master/libfreefare/mifare_desfire.c#L406
Also beware when testing 3DES with a null key, it has the nasty property that ENC(data)==DEC(data). So maybe a source of confusion is also when you assume an encryption instead of a decryption at some step -> it will work on Ridrix data but it's wrong with any non null key.
@doegox Thanks for the response. Do you know more about "older and newer" cards? How old/how new? Is this DESFire EV0 vs EV1 or is this within the same major version?
I have made a test script using pycrypto: https://gist.github.com/dev-zzo/87e0947f3ca0bb6d6baf78dd4d0ecb9c It demo's everything I don't understand about the algorithm. :-)
- If CBC was always used, as libfreefare code suggests, then Adam's data would decode correctly in the right column throughout, which is not the case.
- If CBC were used partially, as the D40 docs suggest, then data in the left column would be correct except the third line, which is the case for Ridrix data, but again not the case for Adam's.
- There is also an option of Adam's data being intentionally broken.
afaik libfreefare is working fine, so better to take it as a model ;) sorry, about to leave for holidays, can't help you right now.
I was not correct about older & newer cards, it's not about cards but commands. AUTHENTICATE_LEGACY == 0x0A is using this weird "reverse" CBC mode AUTHENTICATE_ISO == 0x1A and AUTHENTICATE_AES == 0xAA use proper CBC mode
@doegox I am currently trying to get the "legacy" mode supported properly, as it is the only one supported by EV0 cards. ISO and AES auth modes are supported from EV1 onwards AFAICT. I guess I need more input data here... Have fun on your holidays!
I'll just leave this here... http://en.pudn.com/downloads134/ebook/detail572228_en.html
A quick test with my own key tracing a DF EV1
do_desfire("00112233445566770011223344556677", "079163698cc81654", "fdd62db6b21f2d99", "268577f5d11b1e13", "487dae253a1455ca")
This matches the behavior of ridrix data. I tried several variations on Adam's data but could not make sense of it neither.
@doegox Then it seems like libfreefare has an issue handling the legacy authentication method?
Just to let everyone here know, EV0 "legacy" authentication has been verified to work fine. My big thanks to @shombre for help with testing it!
Hello @dev-zzo I wanted to reproduce your https://gist.github.com/dev-zzo/77e1365d40b0a70f8d33e988412afcb3/revisions proxmark3 read. Is this still working with your Latest commit b73bba3?
@arne182 The commit b73bba3 completely breaks only file-related functionality, which is not finished yet anyway. :-) The basic functionality of getting the PICC identified should work -- please open a bug at my fork if it does not.
I tried it with another reader with the pn532_uart it is responding but it fails to respond on the samsung galaxy s4. The s4 should be able to read the uid but the tag is not found. Using the same UID on the MF_CLASSIC_1K_7B config, android reports the UID correctly.
Hi, is it possible right now to "emulate" a desfire ev1 card (only the part related to the UID) ? Simply answering when asked for the (U)ID (with ATQA 0x0344 and SAK 0X20) ?
R
