1
$\begingroup$

As you know there occured some successful attacks again mifare classic tags (manufactured by NXP) and therefore NXP recommends to replace these tags with some newer products like mifare pro desfire and others.

My question is why don't we encrypt data (with AES, ...) and then translate and store this data to the mifare classic's block, with present 32bit micro controllers it doesn't need so calculation time and there will be a good saving in cost . Why don't companies implement this approach ?

EDIT

tnx all answers. at first my mind from 32 bit mcu was not tag's built in processor,i mean first we separately encrypt plaintext to ciphertext in the mcu based on AES. I have an extra scenario, lets find it's bugs:

  • as you know each tag has a Unique ID(UID) & we define a key for transacting data between tag & reader/writer chip that controlled by the mcu( PCD chip).
  • when tag entered to PCD's operation field,pcd read tag's UID
  • mcu make ENC_KEY with irregular combination of AES_INIT_KEY & uid (each tag will has seprate ENC_KEY)
  • mcu calculate plaintext'hash with its hash function(TEXT_HASH).
  • mcu encrypt plaintext based on AES with ENC_KEY(it makes CIPH_TEXT).
  • mcu transfer & stored CIPH_TEXT & TEXT_HASH to the tag's (mifare classic) via mifare algorithm .

then there are not problems mentioned in answer1, each tag's has unique key & same credit in different has not same CIPH_TEXT

in the second part:

mcu read tag's uid,make ENC_KEY with tag's uid & AES_INIT_KEY ,read CIPH_TEXT & TEXT_HASH with crypto1 & its key from tag,decrypt CIPH_TEXT & TEXT_HASH with ENC_KEY & checked plaintext integrity with its hash value.

i accepted Maarten Bodewes's answer about price case .(tnx a lot) I'm really concerned to read this approach's baugs WBR

Improve this question
$\endgroup$
7
  • 3
    $\begingroup$ 1) Fixing old stuff doesn't sell your new stuff. 2) Those controllers may not support good algorithms. 3) The break may not be caused by bad crypto but rather by some tricks circumventing the crypto so good crypto won't help. $\endgroup$
    – SEJPM
    Commented Sep 8, 2015 at 20:17
  • $\begingroup$ tnx for good answer,i want only find technical reasons then let's focus on 3th state:can you explain more? all data (plaintext) encrypted by AES & strong key to the encoded state(ciphertext) then we transfer it to the mifare classic in the worth state we imagine attacker has keys or sniffs & decodes transferred (stored) data ,then he/she has strong decoded ciphertext what he/she can do ? WBR $\endgroup$
    – Mahmoud Hosseinipour
    Commented Sep 8, 2015 at 20:41
  • $\begingroup$ @MahmoudHD #2 is also a technical reason. $\endgroup$
    – mikeazo
    Commented Sep 8, 2015 at 20:43
  • 1
    $\begingroup$ After reading a bit about the attack it looks like #2 applies. They used a custom algorithm that sucked and ended up being punished for that decision. This would also mean you can't switch the algorithm as crypto is usually implemented as ASIC meaning you can't change function afterwards. $\endgroup$
    – SEJPM
    Commented Sep 8, 2015 at 21:47
  • 1
    $\begingroup$ @MahmoudHD With regards to the upgrade costs: completely wrong. First of all, most of these tags have build in expiry dates; the customer will pay for the replacement. The CPU's in the machines are likely to be cheap as well, buying high end replacements for them is going to cost a lot of money and then there is the man hours involved, the planning for downtime etc. etc.... These chips are very cheap; think euro/dollar cents apiece. Printing is pretty cheap as well for the low range of cards (paper or PVC) - after initial costs for buying the machines in the first place of course. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 9, 2015 at 10:19

1 Answer 1

Reset to default
2
$\begingroup$

Enciphering data using AES and moving that to a card without effective security is not enough to solve some very real security issues; including most preeminently the possibility of

  1. returning a prepaid card to its original state, re-crediting it after use (an adversary can copy the original enciphered data, and save it for future use when the genuine card is empty)
  2. making duplicates indistinguishable form the original (which can multiply stored value, or allow to forge duplicates of an access cards)

Update: it was suggested that the content of the card be enciphered and integrity-protected using a symmetric key derived by the reader from the tag's Unique IDentifier and a master key. This effectively prevents an adversary (not knowing the master key) from altering at will the content of a card, or copying the content of a card to another card with different UID. It however gives no protection at all against attack 1 (which copies the original enciphered and integrity-protected data back to the original card); and only blocks attack 2 if an adversary has some difficulty making a duplicate card with the same UID as the original.

Note: Mifare Classic cards do not use a micro-controller, much less a 32-bit micro-controller (as I wrongly thought the question suggested), which are currently used in rather high-end Smart Cards; many Smart Cards ICs used in mobile phones SIMs, bank cards, transport cards, identity documents.. still use an 8-bit CPU, or 16-bit evolved from 8-bit, like these or these.

Improve this answer
$\endgroup$
5
  • 1
    $\begingroup$ The latest iterations of the high end smart cards have a little more oomph, especially in the CPU department, e.g. NXP "High-performance SmartMX2 CPU with enhanced 8 to 32-bit application instruction set" and the Infineon SLE 78 has a full 16 bit instruction set if I'm not mistaken. Pretty high frequencies as well, I've already started joking about active cooling systems. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 9, 2015 at 10:27
  • $\begingroup$ @Maarten Bodewes: Yes, there has been 32-bit Smart Card CPUs around for ≈5 years. But many mainstream products are 8/16-bit, see here for SLE78, and here for SmartMX2 (at least the later has a 32-bit Public Key Cryptography coprocessor). $\endgroup$
    – fgrieu ♦
    Commented Sep 9, 2015 at 10:50
  • 1
    $\begingroup$ The SLE78 has 32 bit registers, memory bus and 32-bit arithmetic instructions. That makes it pretty close to a 32 bit CPU IMHO. The SmartMX2 chip you are quoting is the low end P40. NXP usually has a cheap option for those customers not going for the full monty (as in all the way, not the meaning of the film); I presume the P60 is sold more (but I haven't got their sale figures). Yes, contact chips have been 32 bit for a while, but usually they are just not cost effective. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 9, 2015 at 11:05
  • $\begingroup$ @Maarten Bodewes: the document I linked to mentions the SLE78 has for main processors (redundant for better protection against fault injection): "Proprietary CPU implementation of the Intel MCS251 standard architecture from functional perspective, represented by two CPUs from hardware perspective", and mentions a "16-bit ALU"; 32-bit features seem to be for co-processors, or/and pipelined. On the other hand, the SLE97 indeed has a full 32-bit main CPU. $\endgroup$
    – fgrieu ♦
    Commented Sep 9, 2015 at 11:57
  • 1
    $\begingroup$ @Maarten Bodewes: I located info on P60: "The central processing unit supports a 32-/24-/16-/8-bit instruction set optimized for smart card applications, which is a super set of the 80C51 family instruction set. The first and in some cases the second byte of an instruction are used for operation encoding". Looks like another 8/16-bit CPU to me, and what's 3 or 4 bytes is instruction+arguments, not ALU width. The only Smart Card CPUs I am aware of that feature 32-bit registers and ALU in the main CPU are ARM-based. $\endgroup$
    – fgrieu ♦
    Commented Sep 9, 2015 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.