Filter-MiFare

From RFID Guardian

MiFare and DesFire (and T=CL and ...) are supersets of 14443-A/3. But, they are different protocols. If a message arrives at a 14443-A port, how can we decide which protocol it is? Let's call all protocols that extend 14443-A/3, l4 protocols -- although MiFare isn't 14443/4.

If it is straight 14443-A, then fine, handle it.

If it isn't, we must choose. Two choices:

• try all protocols one by one. If they are not disjoint, what then?
• let it depend on the authentication. These commands must surely differ between the l4 protocols.

We need a special path for data frames. Some commands are followed by a data frame. Data frames may be a response to a command, or a follow-up. The procotols themselves know. But, if a command solicits a data frame, the upcall chain must be aware where it should be delivered.

So, the upcall chain must be aware of the l4 client layer for data frames, and the obvious way to achieve this is that the command handler sets some state somewhere in the upcall chain. We may be able to use a comparable mechanism for distinguishing between l4 clients. After a (successful?) authentication, the command handler must notify the upcall chain of the current l4 protocol.

Two questions:

• where in the upcall chain do we register the current l4 protocol?
  • in the spoofer -- then no ACL interaction, etc...
  • in the filter
  • in the port via the port_session_descr
• uhmmm... what was this again...

A general question: how do we deal with encrypted frames? After authentication, communication is generally encrypted.