User Tools

Site Tools


project:cchs:access_system:card_format

Mifare Classic 1K

General layout: 16 sectors (0-15), of four blocks each (0-3), 16 bytes per block. (Block #3 of each sector is the access control bits)

  • Block 0 of Sector #0: Read only 'Manufacturer data' (UID etc)
  • Layout proposal: One sector (lets say last sector.. 15) used for CCHS access.
  • * Block #0 will contain the 'check data' - data that needs to match what is on the server
  • * Block #1 will contain the serial number - random bytes that are changed on each access - sent back to the audit log as a check against card duplication.
  • * Block #2 empty.
  • * Block #3 access block - contains the keys A/B as well as the permissions for them.

Security considerations

The (in)security of the MiFare Classic is well documented - in that the encryption on the card itself has been broken, and can be cracked relatively easily (within minutes).

The UID of a NFC card is generally 'burned-in', however, in this instance, there exists 'Chinese Clone' cards for less than $20 which have a changeable UID. (These cards can be detected during handshake). Boards such as the ProxMark are both able to eavesdrop and emulate NFC cards fully.

With this in mind:

  • The access keys will be different from each card - either a random salt stored on the server, or a derived key (i.e KEY = FUNCTION(card_uid, site_key))
  • There are two keys (A,B) for each sector. KeyA should be used for general actions, KeyB for 'permanent' actions such as changing the access block bits.
  • All sectors will be locked out, this prevents Nested/mfoc attack.
  • * Could the 'decrement counter' workaround mentioned in the Nethemba presentation be used? Would require check data to be re-encrypted on each access.
  • We don't propose absolute paranoia with NFC security, rather 'good practice' from the start - Matt

Other common NFC tags

Ultralight/C

  • Smaller, 192 byte tags. Cheaper.
    • Getting more popular for NFC/phone 'action tags'
    • Would be nice to factor the Ultralight C in for future development (clearly even 192 bytes is enough) .. if they can be sourced cheaply in bulk.
  • Version 1 (common in the market place) does not have any security. The 'C' version has 3DES support.
    • However, sectors can be made 'one-time' write.

DESFire

  • Has a full 'application-file system' type structure
  • 3DES support - has a '3 way' handshake to verify both sides have same key
  • EV1 version implements AES as well, along with other security features (random card UID etc.)
  • DESFire 4K is used in myki.
  • Datasheets not available publicly, but libfreefare has a full API for them.

JCOP

  • Fully programmable using Java Card APIs
    • Right down to the protocol packets.. i.e you can emulate other cards with it.
  • Used in every PayPass/PayWave card
  • Also implemented as part of the 'Secure Element' in NFC phones (either as a chip, microSD or in the SIM card) - required for 'card emulation' mode.
  • Cards rather expensive ($10 each), hard, but not impossible to program without tools from NXP.
  • Available as dual-interface (contact chip / contactless versions).

NFC support in Android

  • Extent of Android public NFC API is pushing peer-to-peer messages (NDEF format), or reading from tags.
  • Card emulation would be easiest to implement on reader side (looks like a card), this requires either driving the NFC controller directly (the equivalent of bit banging), or using the secure element with a JCOP applet.
    • State of secure element access is confusing - it appears it is available easily on the Google 'Nexus' platforms and some others relatively easily - maybe not on others? See Secure Element Evaluation Kit for Android
  • A trace of libnfc reveals the methods to set up the reader for NFC P2P (accessible from Android userspace) is vastly different from NFC tag read/write - keep this in mind for software.
    • Using NFC P2P requires a special software stack - how would this fit on a potential smaller/cheaper reader device - are there any timing requirements that need to be adhered to?

NFC P2P

For reasons explained above, the ability to use a NFC smartphone as an access tag is best achieved with Peer-to-Peer NFC. This is where two separate NFC readers can establish communication with each other, as opposed to a reader and a card.

The protocols used for P2P are roughly analogous to TCP and UDP - there can be connection-oriented or connectionless sessions. This presents a large added overhead to the NFC stack (as well as some differences at 'layer 2') that make integrating P2P not as straight forward. Its likely there will be two separate code bases in the reader code - one for tags and one for P2P - and the program loop will need to poll for each alternatively.

Initial research has begun.. but it is anticipated the system will be operational with cards only at first.

Good Overview of NFC P2P contained in draft for secure LLCP (the 'layer 3' mechanism in the P2P stack)

References

project/cchs/access_system/card_format.txt · Last modified: 2015/04/16 19:55 by projectgus