Archives 2010

Java + PC/SC = accessing smartcards from a web page

The Java Smartcard I/O API (javax.smartcardio, JSR 268) introduced in Java 1.6 is the bridge between PC/SC readers and the Java world. Java-based applications and applets may now communicate with smartcards in an interoperable and portable way. This makes it possible for web pages to access data stored in smartcards, or to invoke services running in a smartcard (either running a JavaCard cardlet or whatever native card application).

An interesting extension of this technique would be the ability for  JavaScript to access the smartcards as well. JavaScript is not Java: Java code is compiled into bytecode, then translated into native code and executed by the computer's Java Virtual Machine (JVM). JavaScript is interpreted 'on-the-fly' by the browser's JavaScript engine. This would open new opportunities for developers to build quickly and easily smartcard-aware web-based applications purely in HTML+JavaScript.

It is not difficult to implement such a bridge between HTML+JavaScript and smartcards, creating a GUI-less Java applet that will translate JavaScript function calls into calls to javax.smartcardio methods. There are two technical aspects that must be mastered to do so:

  • The applet has to be signed, as the smartcard is a critical computer's resource, not immediately available to the applets running in the sandbox,
  • The applet has to be scriptable, in order to expose itself to JavaScript through functions and events. But scriptable and signed applets normally mandate signed JavaScript, something we want to avoid to remain 'easy'.

We've written a small yet precise HOWTO that explains the whole process of developing such an applet. You may download it here.

Following this HOWTO, a sample applet has been developed and signed for demos and tests. You can test it online here (the applet is signed with our certificate 'www.springcard.com'. You must accept the signature, otherwhise you will be able to list the readers but not to connect to the cards).

You can develop this type of solution with our products in the SpringCard CSB6 Family (CSB6Prox’N’Roll PC/SCEasyFinger and CrazyWriter) and our NFC readers/encoders (H512NFC’Roll).

Mifare is out of 32-bit IDs

NXP Semiconductors has recently warned their customers that they are running out of unique IDs for the Mifare Classic family. A detailed application note is also available to give precize answers to technical questions.

Since the beginning, every card in the Mifare Classic family (1k, 4k, Mini) has a 32-bit identifier, said to be unique (4-byte UID according to ISO 14443-3 A standard). The reader uses this identifier to "see" and to select the card (anticollision + activation loop). Afterwards, the reader's Crypto1 engine also has to know this identifier in order to perform the mutual authentication, to gain read or write access on card's data.

Theoretically, 32 bits would mean that 4.2 billion cards coul'd be issued with different IDs (4 294 967 296 exactly). But as some values have been reserved or assigned by ISO to different uses, only 3.7 billion unique IDs were practically available. Therefore, NXP expects to run out of unique identifiers for Mifare Classic by the end of 2010.

Fortunately, ISO 14443 standard allows longer IDs: either 7-byte IDs ("cascade level 2", widely used for years, by Mifare UltraLight and Desfire for instance) or 10-byte IDs ("cascade level 3", but with no practical example at the date of writing). To overcome the 32-bit limit, NXP will introduce a new generation of Mifare Classic cards using 7-byte IDs. As a consequence, applications working with card IDs may have to be updated to accept longer numbers.

All SpringCard readers, whatever the version, support the whole ISO 14443 standard, including 7- or 10-byte IDs. But the Crypto1 authentication scheme has to be slightly updated to support the longer ID. In our contactless products (SpringProx, CSB, Prox'N'Roll, etc), this is implemented since version 1.51. Therefore, customers that need to read/write new Mifare Classic cards having 7-byte IDs (as well as Mifare Plus) shall make sure that their products run firmware 1.51 or newer.

SpringCard and Effitic ready for 'at-home' card-based services

Effitic, a french software engineering company, has set up a working demo that demonstrates how public transportation cards could be reloaded at home thanks to SpringCard's contactless readers.

Effitic

In this architecture, all the business logic and the security components (SAM or HSM) are centralised in Effitic's back-office server. A lightweight Java applet runs in a standard web browser to communicate with the smartcard reader through the PC/SC middleware. The applet installs itself automatically upon first access to the service whatever the system/browser.

The demonstration is typically performed with Calypso cards and a SpringCard Prox'N'Roll PC/SC contactless reader. As Prox'N'Roll PC/SC complies to the CCID standard, a driver is available -and installed automatically in most cases- on current desktop operating systems.

This setup is a cost-effective solution for at-home reloading of public transportation cards. This removes the need for a dual-interface card as the Prox'N'Roll operates contactless (13.56MHz RFID interface, compliant with ISO/IEC 14443 A and B, ISO/IEC 15693, Calypso/Innovatron, and with current disposable contactless tickets).

It also opens new opportunities and a new approach of user's experience with his/her contactless card or NFC mobile phone. In fact, this web-based contactless smartcard architecture is not limited to transport ticketing but could be the basis of a new generation of innovative projects in various fields such as e-ID/e-gov, loyalty, entertainment and online gaming, events and sport ticketing, etc.

Java PC/SC applet

Effitic back-office server communicates with the Prox'N'Roll PC/SC smart card reader thanks to a Java applet

Billing snapshot

Customer uses his/her credit card to buy a new ticket to be loaded into the Calypso card

Card reloaded snapshot

The new transport ticket is loaded in the contactless Calypso card. A receipt is sent by e-mail.

Cardpeek - open source tool to read the content of smartcards

We've discovered a new open source project (lead by "L1L1") that sounds promising.

Cardpeek is a Linux tool to read the contents of ISO7816 smartcards. It uses a PC/SC reader to communicate with the card, and its GTK GUI represents card data is a tree view. Cardpeek list of supported cards is expandable thanks to a scripting language. Currently, the tool can explore EMV cards, Calypso cards (including the Navigo pass from Paris area, with translation of the station names -this part developed by pterjan), Moneo cards (french ePurse) and Vitale (french health card).

Here's a few snapshot I've taken with a Prox'N'Roll PC/SC and my own Navigo card (Paris' Calypso card)

Cardpeek + Prox'N'Roll PC/SC

Selecting Prox'N'Roll PC/SC reader

Content of a Calypso card: ATR and list of contracts

Card content explained: ATR and list of contracts

Content of a Calypso card: transport log

Card content explained: transport log, with station code translated to actual names

Project homepage : http://code.google.com/p/cardpeek/

A few more explanations on freshmeat : http://freshmeat.net/projects/cardpeek

Create and read NFC tags with SpringCard NFC Tool and NFC Decoder

NFC Tags in a nutshell

An NFC Tag is a regular ISO 14443 card (either a memory card or a microprocessor-based smartcard), holding a specific content. Depending on this content, the "reader" will perform automatically a predefined action. Typical actions are :

  • open a URL (Internet address),
  • dial a number or send an SMS (if the reader is a mobile phone),
  • launch a software,
  • etc...

NFC tags are for instance embedded in Smart Posters, a new media for advertisement. Users seing the poster and touching its NFC tag with their NFC-enabled mobile phone or smartphone they may receive easily coupons or detailed information, or be prompted to buy online the advertised goods.

NFC logo : identifies NFC Compliant devices

The NFC Tag logo has been designed by the NFC Forum to identify NFC Tags.

NFC Forum, the organisation in charge of NFC standardization, has registered 4 types of NFC Tags :

  • NFC Type 1 tags :  Innovision Research & Technology TOPAZ chips (proprietary communication protocol on top of ISO 14443-A modulation)
  • NFC Type 2 tags : NXP MIFARE Ultralight and Ultralight C chips (proprietary communication protocol on top of ISO 14443-A modulation)
  • NFC Type 3 tags : Sony FELICA chips (proprietary modulation and communication)
  • NFC Type 4 tags :  standard ISO 7816-4 smartcards using ISO 14443 A or B up to layer 4

NXP and Nokia also support using NXP MIFARE Classic (1k/4k) tags. Visit NXP's website for more information on how to make NFC tags using their chips (including MIFARE DESfire as Type 4 tags).

The format on the content stored in the tags is specified by NFC Forum in NDEF standard (NFC Data Exchange Format).

Getting started with NFC Tags thanks to SpringCard readers and software

SpringCard has developed a set of software -with sources included in the new release of the SDKs- to demonstrate how NFC tags are encoded and processed by SpringCard contactless readers.

Customize your tags using NFC Tool

NFC Tool is a desktop application (Windows) to encode and read common NFC tags. NFC Tool works with PC/SC readers (Prox'N'Roll, CrazyWriter or CSB6 namely).

NFC Tool allows you to read/write NFC content on your cards

An example of use of NFC Tool with a Mifare UltraLight Card

Easily read and write NFC content in your cards using NFC Tool : Choose between SmartPoster, Text or URI ; fill in your URL or Text ; encode it to generate the NDEF and write it to your card.

At the date of writing, NFC Tool supports the following tags :

  • MIFARE Classic cards (standard 1K/4K)  as NFC Type 2 tags ;
  • MIFARE UltraLight (MF0ICU1) and UltraLight C (MF0ICU2) cards as NFC Type 2 tags ;
  • TOPAZ by Innovision cards as NFC Type 1 tags.

NFC Tool can be found in our PC/SC SDK (C# application for .NET framework).

Read NFC tags on your Pocket PC using NFC Decoder

NFC Decoder is a lighweight application for Windows Mobile (Pocket PC) that allows you to open an URL from an NFC tag card. NFC Decoder works with either SpringProx-CF, SpringProx-CF UP or SpringWAP through SpringProx API. It supports MIFARE 1K, MIFARE 4K and MIFARE UltraLight or UltraLight C as NFC Type 2 tags.

NFC Decoder

An URL found on tag with NFC Decoder

(C# application for .NET compact framework).

Mifare UltraLight C : low-cost yet high security

NXP (formerly Philips SemiConductors) Mifare UltraLight chip (MF0ICU1) is a inexpensive contactless memory, widely used to make disposable transport tickets or other low-cost identification tags. As MF0ICU1 lacks of authentication or even password protection schemes, the reading application has to way to determine whether the serial number and the data come from a genuine card, or from a a spy/replay device emulating it  (read this article for a few details).

The new Mifare UltraLight C chip (MF0ICU2), while remaining compatible with MF0ICU1, now provides a strong mutual-authentication algorithm, based on the standard 3DES (Triple-DES) algorithm. This allows to make sure the card in front of a reader is genuine (the application and the card share the same secret key).

A Mifare Ultralight C embedded in a wristband, used for ticketing and pre-payment during the Gala ECE event.

Gala ECE is a successful example of the Mifare UltraLight C's use for ticketing and payment. To prevent the risk of theft in this sort of giant night-club, the bars were not allowed to accept bills or coins ; wristbands had to be credited at a few kiosks, and then used as electronic purses. When it comes to money, security is a major concern. The organisators wanted a secure purse solution yet remaining compliant with low-cost tags, and SpringCard successfully help them to specify and develop the it on top of Mifare UltraLight C.

Here's a few hints :

  • Thanks to a 3DES-based key diversification algorithm, each card has its own secret key (the secret key of the card is computed from a 'root' key and the ID of the card). Doing so, if one key gets corrupted, the whole system remains safe. Only the 'root' key is critical,
  • Confidence is based on the dynamic mutual-authentication (based on 3DES). This removes the need to digitally sign (or MAC) the data stored in the card, so the whole memory remains usable to store informations (including a small transaction log),
  • Selective locking and protection of different blocks in card's memory allow a fast reading yet ensure that no writing could be made without prior authentication,
  • As the card doesn't feature a true anti-tearing system, we choose to read-back the data after writing, but thanks to the fast USB link between the computer and the Prox'N'Roll, the added time is not noticeable for the consumer.

This experience has shown how easy it is to implement quickly a large scale ticketing and pre-payment system, in the same price range as 'conventional' memory cards (Mifare, Mifare UltraLight, or their equivalent in ISO 14443-B), but with a very good security level -that was before achievable only using more expensive smart cards.

Contactless ticketing and pre-payment using Mifare UltraLight C and Prox'N'Roll

Last saturday, SpringCard Prox'N'Roll PC/SC was the core component of the access control and payment system during the annual gala of french high-school École Centrale d'Électronique (ECE) located in Paris. NXP Mifare UltraLight C chips were embedded in the disposable wristbands (featuring the SpringCard logo) that were worn by 3000 attendees.

Starting from SpringCard SDK, ECE students working on the project have written in only a few days a dedicated cashier software (in C# for .NET). A clever use of UltraLight C security capabilities (3-DES authentication) allowed them to make sure that no money could be lost during the event.

The team appears in a short video that aims to promote the concept :

Calypso Explorer now available for download

SpringCard contactless readers are often used together with Calypso cards, that are used worldwide by some major transport operators ('Navigo' in Paris for instance). We are now offering for free two software utilities we've developed to retrieve and explain the content of those cards :

  • Calypso XML Dump is a CLI written in C that reads the files of a Calypso card ('1TIC.ICA' card application), applies Intercode rules to decode the records, and export the result as XML files. This is convenient to make dumps of cards for later processing.
  • Calypso Explorer is a .NET based software with an 'explorer-like' GUI. It also reads the files and applies the Intercode rules, then directly show the result in its window.

Both software work with PC/SC readers. They make use of SpringCard library for Calypso (provided as a DLL in the package).

Download SpringCard Calypso Explorer software

Complete source code is provided, showing how you can embedd this DLL into your own sofware. It allows fast and easy development of PC-based applications using Calypso cards. Our LICENSE allows you to use the software freely (binary and/or source) provided that you use it together with one of our hardware products (to name a few : Prox'N'Roll PC/SC, CSB6 PC/SC, CrazyWriter PC/SC).

Screenshots :

Calypso Explorer : select the PC/SC reader
Calypso Explorer : choosing the PC/SC reader

Calypso Explorer : card's details
Calypso Explorer : dump of the card.
It reads Card.EnvHolder.Record #1.Environment.Network = 250901. This is a 'Navigo' card, from Paris network (subway and suburbian trains).

Calypso XML Dump
Calypso XMP Dump : the same card, shown as XML.
Call calypso_xml_dump -o xml_file.xml to redirect the output to a file.

References :

  • Calypso is a standard initially developed and promoted by Innovatron, SNCF and RATP in Paris. It is now promoted by a non-for-profit-organisation, the Calypso Network Association. Note that access to the specification of the cards is limited, and that some features of the cards have been patented by Innovatron (secure session and ratification). Our customers shall buy readers including the patent licence-fee ('-C' suffix in the part number) if they want to perform a complete Calypso transaction.
  • The Intercode specification describes how the record shall be structured (the final aim is to achieve interoperability between transport networks). It is based on the data types described by EN1515 standard. The specification is available at http://www.billettique.fr/IMG/pdf/intercode_2_amendement_1k.pdf.

Calypso Explorer has been developed with SharpDevelop IDE, a really good alternative to Microsoft Visual Studio (fast, easy, and on top of that, free and open). Calypso XML Dump has been developed with Microsoft Visual C++ 6.

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.