-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for NTAG 424, DESFire Lite, and some limited DESFire EV2 #116
Comments
Is NXP really trying to have security through obscurity? Didn't they learn from their crypto-1 faults? Btw, thanks for doing such a great work for the community. (Y) |
NXP’s designs don’t rely on proprietary crypto anymore. If anything I think they are keeping their specs under NDA because they don’t want to help people make knockoff chips. But that’s just a guess. It is frustrating, but I think they’ve learned their lessons from the MIFARE Classic days. |
Desfire EV2 is a EAL5+ certified product and when you do such CC certification, limiting accessibility of information that could potentially help attackers is valued. |
Is that really one of the CC EAL5+ requirements? If so, that is pretty lame. But I don't see any obvious correlation between CC EAL certifications and NDA requirements, aside from the "+":
|
It's not a requirement, it gives you extra points and you need to reach some amount of points to get your certification. So it's not impossible to be more open and get certified, but it's harder. And going from EAL4+ to EAL5+ is already pretty hard to achieve... |
How unfortunate. I was under the impression that EAL certifications were more about design practices and confirmability/testing than gimmicks like limiting access to the specification to a software interface. In any case, it is what it is, and I doubt it will change—but I was pleasantly surprised that both the NTAG 242 DNA and DESFire Lite specifications don't need NDAs. I managed to pick up a few NTAG 242 DNA tags a few weeks ago. |
Hello guys. I have been challenging the EV2 just today in order to implement a library in Python 3. Could say some examples in the application notes are somehow "internally inconsistent". I think it may be useful to you guys, I have working test cases for AuthenticateEV2First and CommMode.MAC/FULL: Also there is my implementation in the same file, may save you some time if you look at it. Unfortunately right now I don't have time to port it to libfreefare and I don't even have the devices physically on site to test anything. |
https://github.com/islog/liblogicalaccess support the DesFire EV2 I'm pretty sure we can learn stuff there |
Hi everyone, I'd like to contribute to this project adding support for the ntag424. I've been working with it for my job so I think my help could be useful. What's the current status of the development? |
Is it possible to use NTAG 424 DNA tags with libfreefare (using only basic functionality), with the NTAG21x support? In other words, are NTAG424 tags backwards compatible with NTAG21x? |
@astrand 424 and 21x have very very little in common:
I think these two need separate support. |
seems that https://github.com/icedevml/ntag424-ev2-crypto is not available anymore? |
libfreefare
currently supports the legacy MIFARE DESFire D40 and MIFARE DESFire EV1. It supports EV2 only to the extent that EV2 is able to function identically to a EV1, but no EV2-specific functionality is currently supported.This is complicated by NXP's requirement that the full datasheet for the DESFire EV2 only be released under NDA. The short datasheet is not adequate to implement support for the new features such as the new EV2 security mode, ability to update arbitrary records, advanced key management, proximity detection, etc.
BUT...
NXP has recently released two new chips that use a subset of the EV2 command set:
Critically, both of these chips have the full datasheets available! 🎉
By carefully reading between the lines from both datasheets, we should have enough information to implement the following features:
It's unclear if there is enough information in the datasheets to piece together how the multiple-keys-per-access-right feature works, but that might be possible, too.
In addition, the NTAG 424 DNA is itself a pretty cool chip:
So, by adding support for the NTAG 424 DNA and MIFARE DESFire Light, we end up getting some support for a few DESFire EV2 features, even though we don't have access to the full datasheet for that chip.
So I'm considering adding support for these chips. Neither are very common at the moment. I'd consider adding the NTAG 413 DNA as well, but it's datasheet is only available under NDA.
Thoughts? If I do this, do you have any guidance/opinions on how the API should work?
The text was updated successfully, but these errors were encountered: