New firmware for all SpringCard PC/SC couplers based on the H663 core

SpringCard has just released a new firmware version, tagged 2.00, for its H663 core.

The H663 core is a versatile contactless+contact module, which supports virtually all proximity/RFID HF chip cards (ISO 14443 & ISO 15693 standards, including Mifare, Calypso, etc), NFC-enabled mobile phones or other objects (ISO 18092, peer-to-peer in initiator mode, passive communication scheme), and could also accept up to 5 contact smartcards (ISO 7816, one ID-1 card and up to 4 SIM/SAM ID-000 cards).

SpringCard H663 is the foundation of the largest family of RFID/NFC USB PC/SC readers on the market:

  • The H663S and H663A "bare" modules (designed respectively for either a Symetrical - balanced or an Asymetrical - unbalanced antenna)
  • The H663-USB OEM PC/SC ready-to-use contactless coupler (H663 core + antenna)
  • The CrazyWriter HSP, a complete multi-slot contactless+5 contact PC/SC coupler made for OEMs
  • The TwistyWriter HSP, a contactless+ID-000 PC/SC coupler made for OEMs
  • The CSB HSP, a desktop PC/SC coupler featuring contactless, 1 smartcard slot and 3 ID-000 slots
  • The Prox'N'Roll HSP, a brand new version of SpringCard's best selling desktop contactless coupler.

This new firmware version provides only a few new features, but introduces a new software architecture based on FreeRTOS which dramatically increases the device's performance for a better transaction time - particulary when accessing numerous slots in the same transaction.

freertos

How to upgrade

To upgrade your H663-based product with this new version, please refer to our H663/H512 Firmware Upgrade Procedure.

The 2.00 firmware file is here: uc3b0256_rc663_h663_2-00.hex

(note for future readers: please always use the latest firmware version using this permanent link).

From 30/04/2015, all H663-based products will ship with this version (instead of earlier 1.81).

Some new feature

Adding the reader's serial number to the slot names under Windows

Starting with version 2.00, the H663 family is able to insert the reader's serial number in the name of the PC/SC readers as exposed by Windows' SCardListReaders API call. On machines with numerous readers attached, this makes it possible to know which physical reader is actually bound to a logical slot without querying the reader through a SCardControl call.

To enable this feature, download the latest version of MultifConf; create a new project for the H663-product you own (CrazyWriter HSP typically), and in this project scroll down to "Misc. tricks". Then find the "Insert the serial number in the name of the slots" entry and turn it ON. apply the configuration to the reader(s) (Project -> Write Configuration into Reader), restart the reader, and enjoy!

multiconf-h663-tricks

 

 

Why one shouldn't trust card's serial number

Both ISO 14443 and ISO 15693 mandates that the contactless/proximity cards or tags all have a 'more-or-less unique' physical identifier, that is required to identify the card or tag during the initial discovery process (and during the anti-collision loop when there's more than one card in the field).

This identifier is called UID in 14443-A and in 15693, PUPI in 14443-B. But whatever the name, we write 'more-or-less unique', because nothing mandates this identifier to be actually unique (PUPI stands for Pseudo-Unique PICC identifier). Sometimes it is a random number, sometimes a fixed number shared by a large set of cards. More than that, nothing makes it technically impossible to have two cards with the same physical identifier.

Anyway, in the early years of 13.56MHz technologies, a lot of systems have been designed that use this physical identifier as the only 'key' to recognize either a human (the card holder) or an object (RFID-tagged). Nowadays, a lot of systems still rely on this 'key' to access services or to claim credentials. This could be loyalty coupons, stadium or gymnasium entry, physical access control, whatever service where the physical identifier is the pointer to some database records.

SpringCard has always adviced its customers not to rely on the physical identifier for any 'serious' application, where someone could steal money or enter a place he shouldn't simply by cloning a physical identifier, because  it has been known for years that 'forging' a physical identifier is not difficult for the man of the art :

  • Tools used in the laboratories or for production (Micropross or SmartWare to name a few) are able to emulate any card, and require no specific skills (just some money anyway),
  • Tools used by RFID-enthouastics (or RFID-hackers) such as ProxMark iii or OpenPICC are able to do the same just by writing a few lines of code - and they cost almost nothing,
  • NFC chipsets are now widely available. As a 'good-practice', their manufacturer don't let the user define freely all the bytes of the identifier when running in card emulation mode, but I wouldn't bet that no backdoor exists to overcome this.

Anyway, it is generally admitted that the risk was 'acceptable' in most situations, mostly because the tools that may emulate a card don't look like a card, so any visual inspection of the card (or just a human presence or a camera nearby) is likely to prevent the fraud. But this is not true, as we'll see now.

Atmel has a family of contactless memory cards called CryptoRF. The biggest one is a 8-kB card called AT88SC6416CRF. Note that the very-first page of its datasheet clearly says 'User-defined Anticollision Polling Response'. It looks like Atmel has opened Pandora's box, making it possible to put any physical identifier in their cards - in other words, making it possible to clone very easily any physical identifier (and of course, as they are real cards, they can be printed to look just like the genuine one).

Here's a step by step demo (it has been done using 'console' access to SpringCard Prox'N'Roll running in legacy mode, but this is transposable to any product supporting ISO 14443-B). We use two cards to demonstrate how we clone the identifier :

  • The 'source' card is a 'Mobib' card (Calypso-compliant, STIB network),
  • The 'target' card is an Atmel AT88SC6416CRF. It is totally blank (out of factory), and one may get free samples rather easily at Atmel's.

Mobib card

1. We retrieve launch the card discovery process ('poll' command) and retrieve the PUPI of an ISO 14443-B card. This is our Mobib.

CryptoRF card

2. Let's do the same with our Atmel memory card. Out of factory, they all have the same PUPI : FFFFFFFF.

3. We send three  commands to the cards :

- a. we select the card (this is an ATTRIB, but we do not use the 'attrib' command as the card is not T=CL compliant),

- b. we select the first user zone (seems to be required before trying to access system zone),

- c. the system zone is write-protected, we gain access by sending the password (default password specified in datasheet).

4. Et voila ! The Atmel card has exactly the same identifier as the genuine Mobib.

Note that we should have also changed the protocol bytes that follow the PUPI in card's ATQB. This would have only required one more command.

So, the moral is, never trust the identifier returned by the card. Even the database-centric architectures shall implement a decent dynamic authentication between the card and the 'system' (application, server, SAM, whatever) to ensure a decent security level.