Comments (46)
@Maxhy I will give LibLogicalAccess a close look this weekend. :-)
from chameleonmini.
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. :)
from chameleonmini.
That looks great 😄.
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.
from chameleonmini.
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... ;-)
from chameleonmini.
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.
from chameleonmini.
I think it's best if you create issues in my fork for any problems you might discover. :-)
from chameleonmini.
I second this. MIFARE DESFire is a must.
from chameleonmini.
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
#31 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC90mE5Tr35IfzaoBNtkZoKTbtVftMTmks5qzkhlgaJpZM4KVkDW
.
from chameleonmini.
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 :) )
from chameleonmini.
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.
from chameleonmini.
Oh well. I'll get things rolling in my fork.
from chameleonmini.
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.
from chameleonmini.
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.
from chameleonmini.
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.
from chameleonmini.
@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)
from chameleonmini.
@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.
from chameleonmini.
@dev-zzo I can confirm your assumption, DESFire EV1 and EV2 are fully backward compatible
from chameleonmini.
Quite impressive! Like to see the way you implemented it in your Code.
from chameleonmini.
@skuep The code is public at https://github.com/dev-zzo/ChameleonMini/tree/desfire
from chameleonmini.
This is very impressive, we really like your work and look forward to any progress you make!
from chameleonmini.
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.
from chameleonmini.
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
from chameleonmini.
@dev-zzo It looks like you have your old Makefile fix for compiling under Windows, which breaks up compiling under linux.
from chameleonmini.
@geo-rg @exander77 I have rebased my branch to master's HEAD, it should be OK now.
from chameleonmini.
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.
from chameleonmini.
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
from chameleonmini.
@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.
from chameleonmini.
I just tested emulation on some doors, I had success with some doors, but not with all, maybe related to the speed?
from chameleonmini.
@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.
from chameleonmini.
@exander77 please capture the exchange for the ones that didn't work; you can use proxmark3 for that.
from chameleonmini.
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 :-)
from chameleonmini.
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?
from chameleonmini.
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
from chameleonmini.
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.
from chameleonmini.
@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?
from chameleonmini.
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.
from chameleonmini.
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
from chameleonmini.
@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!
from chameleonmini.
I'll just leave this here...
http://en.pudn.com/downloads134/ebook/detail572228_en.html
from chameleonmini.
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.
from chameleonmini.
@doegox Then it seems like libfreefare has an issue handling the legacy authentication method?
from chameleonmini.
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!
from chameleonmini.
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?
from chameleonmini.
@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.
from chameleonmini.
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.
from chameleonmini.
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
from chameleonmini.
Related Issues (20)
- Desfire adpu processing for real iso-8716 HOT 77
- enabling R(Nack) resend HOT 8
- Create a project to keep track of misc DESFire support TODO tasks? HOT 5
- Emulation mode - Responding to external readers HOT 3
- Problems with external USB readers running ``CONFIG=MF_DESFIRE`` HOT 3
- Where to download the firmware binaries built with the emsec/ChameleonMini actions scripts? HOT 2
- Lost ability to store card data to FRAM in all releases after Jul 08, 2022 HOT 2
- Some Questions about the ChameleonMini
- DESFire: Unable to auth to apps unless authed to the PICC master app first HOT 3
- LED not showing after flashing upgraded firmware HOT 12
- Mifare Ultralight EV1 Emulation Support HOT 4
- cannot access device at all HOT 2
- Issues with Mifare DES-Fire Emulation HOT 3
- Connect device to the LabVIEW HOT 2
- No communication between old NFC reader and ChameleonTiny Pro HOT 6
- Datasheets and other information about debugging with the ChameleonMini HOT 3
- Set new UID HOT 3
- MIFARE DESFire EV1 8K HOT 2
- How can I emulate MIFARE DESFire EV1 8K with Proxmark3 HOT 1
- Conflict in 'Uid' Variable Definitions Across Different Files HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chameleonmini.