Desfire Vs. iCLASS


which is more secure DESFire or iClass?

Hello Ibrahim

In most ways, they are equal. For example:

  • 13.56 MHz transmission
  • 3DES Encryption
  • ISO14443A or B compliant
  • Up to 4Kbyte storage

The real practical difference is not security, but licensing. In order to manufacture cards/readers to work with DESFire credentials, the implementation is standards based (ISO14443) and free. In order to build an iClass solution, one must license the information from HID.

There are products that do both, ie:

Consider this card is made by HID: they don't levy a license fee against themselves for the iClass part, and then use the license-free DESFire standard for the other format.


I beg to differ, but the question was specifically "which is more secure" (and not "is iClass secure enough"). To that question, there can only be one answer: DESFire.

iClass has been cracked, DESFire has not. This even explains how to do it. This also provides a vast amount of information surrounding iClass' card security.

While they have corrected the security flaw with a new hardware release, there are still massive amounts (millions, maybe?) of iClass readers that share this issue. And their iClass Elite "higher security solution" has been put into question here.

I think it is especially foolish to claim any lock is unpickable {edit: 'more secure'} simply because it hasn't been done {edit: exploited} yet.

Fundamentally, DESFire uses the same encryption type as iClass. Whether or not it has been exploited yet is a function of effort, not possibility.

Fundamentally, DESFire uses the same encryption type as iClass.

Sir, although you are correct in your assertion, I believe it is only fair to Mr. McRae to state that security is more than just the laboratory cipher algorithims to be considered. Security is only as strong as its weakest link, and in the case of iClass the majority of the exploits that have been discovered revolve around the handling, passing and reuse of master keys, not the brute force exploitation of the ciphertext..

Certainly it would to foolish to insist that these periphery issues are not just as important as any other link in the chain.

3DES as well as AES when done right is still for all practical purposes undefeatable today. And certainly not in 6 or 10 hours like in most of these attacks.

I think it is especially foolish to claim any lock is unpickable simply because it hasn't been done yet.

I'm not sure what the guidance intended here is, seeing as such a claim was not made by Mr. McRae. Furthermore even if the statements truth and relevance is not challenged, should we take it to mean that locks cannot be judged to be more or less secure based on whether they have been picked yet?

"Furthermore even if the statements truth and relevance is not challenged, should we take it to mean that locks cannot be judged to be more or less secure based on whether they have been picked yet?"

Actually, I mean that claiming DESFire is more secure because it has not yet been cracked is not a strong statement towards it's overall security.

Using the lockpicking example: no thief bothers picking a lock. They take a hammer or prybar and beat a door down, break a window, or walk in through an overlooked opening.

In the same way, 'security' for iClass or DESFire should not really be judged by if a team of college grad students managed to decode or spoof a card with hex generators and modified readers. The apparatus and technique for doing so is frankly too obscure, and there are easier ways for thieves or bad players to gain entry.

Keep in mind that 26-bit Prox has been cracked for a decade and is unencoded in open air. Yet, 26 bit Prox is still a mainstay format widely sold in distribution today.

Now, we can talk about whether or not security managers SHOULD BE more concerned about this; but the fact is they are not.


I didn't claim that DESFire is unbreakable but I did claim that DESFire has never been broken. This is a fact. I don't know if some doctorate student 25 years from now using a future supercomputer will be able to brute-force crack DESFire but today, with all the technology available, this has never been done. It says a lot as to the security of the DESFire encryption.

iClass has been broken (by their own carelessnes, by the way-- not through some brute force attack!) and their ultimate fix, the iClass Elite, has also been broken.

iClass and DESFire are NOT equivalent. DESFire is 128-bit, iClass is 64-bit.

The question was "which is more secure" and the answer, no matter how you want to look at it, is DESFire.

Hello Mark:

Do you agree that vulnerability to brute force attacks are not a good gauge of 'security'?

I almost sound like an HID-apologist, which I am not. However, I think that calling one type of card 'more secure' compared to another based on resistance to obscure exploit is not useful and misleading.

The practical security weakness of iClass credentials are found in DESFire. I can steal a card and misrepresent who I am to a system. I can clone, and therefore spoof DESFire. The difference in bit values just means it takes more time, not necessarily more effort to gutter DESFire.

I think any disagreement we have is in how the label 'more secure' is being used. My point is that in terms of practical risk there is no difference between the two forms.

Thanks for thinking about this! I enjoy the discourse.

Hi Brian,

You're right, it is possible to clone any of these cards. If I can get my hands on your card and have a few minutes with it, I can copy it without any issue. But there is a significant difference between that and the error that HID did with their iClass.

Now, the iClass encryption key is pubicly available on the internet and the option a Mr. Badman now has is not just to copy your card (but I have to get my hands on it and keep it for a short period of time to clone it...not an easy or obvious proposition) but to actually produce your card. Mr. Badman just needs to know your site code, card number and bit format (a very easy thing to do: they sell these cards through distribution, the site code and card numbers are written the the card boxes and sometimes the cards: the site codes and card numbers appear in the access control software and are available to any number of operators).

This is why DESFire is more secure than iClass. If I was an end-user with a high concern for card integrity and security, I would not go the iClass way (nor the Mifare Clasic way eithr, this has also been cracked and the encryption keys are also pubicly available). I would go with DESFire

Thanx Brian

There is another thing that confuses me. Many readers' datasheets mention that they read ISO14443 A & B serial number only ... are all acces control systems function the same way (reading only serial numbers)? the data stored on the application area in the card has no role in access control, is this right?


I'm not sure if you were adressing this question specifically to Brian - sorry if I'm stepping in --

all smart cards (Mifare, DESFire, Mifare Classic, iClass, etc...) are manufactured with an unencrypted, unsecure card serial number or universal ID (UID or CSN) that is on one of the sectors of the card. In general, most smart card readers (and there are MANY out there) will read their technology's CSN. By that I mean that a DESFire reader from most manufacturers will read other manufaturer's DESFire card CSN. The issue with this is that the CSN is NOT secure not encrypted. So if I have the right equipment, I can easily copy your card's CSN and pu it on another card. If you care about security of a facility, this is not the way to go.

Most card readers will not pass though the actual CSN- they will take it and convert it to a standard wiegand format and then output it in a mode that is acceptable to acess control controllers (for example: a CSN could be a long number but when converted by the reader to 26-bit wiegand it would come out as 225:23456 (3-digit site code between 0-255:5 digit card number between 0-65535). So the access control systems are not receiving the card serial number per se, they are receiving a wiegand data number in the bit format that they expect.

If you're considering using the CSN as the unique credential number for a site that has a high level of security (your original question was concerning the level of security between DESFire and iClass...), don't do it. It is extremely easy to acquire and copy the CSN of a card (even of the most secure DESFire format). So don't choose a reader and card format based on its ability to read the CSN, this is not a secure number to use for access control applications.

Thank you very much

Just because,

what about iClass SE?

iClass SE is a progression of iClass format that uses data signatures as well as encryption. Using a data management concept HID calls SIO: Secure Identity Object , HID makes sure that individual data is encrypted (ie: an Access Control ID Number), then packaged together and signed (ie: This data belongs to Ross Andersen), then packaged together with other kinds of data (Ross Andersen's Employee Record), and signed one last time (ie: This is Ross Ansersen's Identity).

SE cards and readers support this elaborate layering. They readers can decrypt just what they need to open a door, but also check to make sure the 'data package' is complete. If you try to counterfeit someone's identity, SIO requires you do the entire job not just the piece you need.

Now the real question: Do many access systems benefit from this? Nope. It is still possible to misrepresent yourself and use someone else's badge to gain access. SE just makes it really difficult to steal credential information electronically.

iClass SE is also the 'NFC' reader, so if your phone has an NFC credential, the SE line can read it.

Bottom line: iClass SE is like 95% structure for 1% difference in real life use. In 2014, not a big deal... maybe in 2024?


i am reading this post and i am wondering how this days found DESfire...