Introducing the new FunkyGate-IP NFC

SpringCard's technical team is proud to announce the launch of a new generation of contactless readers for high-end access control applications, the FunkyGate NFC family.

Using the same shell as previous generation's FunkyGate-DW (Dataclock, Wiegand and RS485 interfaces) and FunkyGate-SU (RS232 and USB interfaces), the FunkyGate NFC family introduces a brand-new member, the FunkyGate-IP NFC.

As the name suggests, the FunkyGate-IP NFC brings the power of TCP/IP up to the door or gate. A standard RJ45 plug connects the reader to any Ethernet LAN (10 or 100 Mbps). More than that, the FunkyGate-IP+POE NFC reader is powered directly by the network (Power Over Ethernet), thus removing the need for the classical 12V power cable.

The FunkyGate-IP+POE eases the job of wiring the building to before installing the access control system. With only a single Cat5e right to the door, the reader is operational as soon as it is plugged to the network.

The FunkyGate-IP+POE eases the job of wiring the building before installing the access control system. With only a single Cat5e right to the door, the reader is operational as soon as it is plugged to the network.

The FunkyGate-IP NFC and FunkyGate-IP+POE NFC readers take full benefit of SpringCard's know-how in all the various 13.56MHz protocols, and pave the way for a easier and wider use of NFC mobile phones in access control and identification applications.

SpringCard MultiConf is a new, versatile, configuration application for all SpringCard products. Define the FunkyGate-IP NFC's configuration, write this configuration into a Master Card, apply this Card to all the readers you want to configure, and voila!

SpringCard MultiConf is a new, versatile, configuration application for all SpringCard products. Define the FunkyGate-IP NFC's configuration, write this configuration into a Master Card, apply this Card to all the readers you want to configure, and voila!

Thanks to the 4 card processing templates -a concept shared with the Prox'N'Roll RFID Scanner and among all SpringCard standalone readers-, the FunkyGate-IP NFC is able to fetch virtually any data from current contactless cards and RFID tags.

The 'NFC' in the product's name denotes the exclusive ability to support new reading schemes based on NFC Forum's concepts :

  • Read an NDEF record stored on a NFC Tag and retrieve its data,
  • Receive an NDEF message from a mobile phone, using NFC Peer-to-peer technology (SNEP over LLCP, Push mode : PUT request from smartphone to reader),
  • Get data from a card-emulation application, possibly running on an Android system thanks to the HCE (Host Card Emulation) feature.
Thanks to Android's 4.4 HCE mode, the FunkyGate-IP is able to get an identifier or perform a transaction over the NFC smartphone, even in screen-off mode. (this is also an unusual selfie)

Thanks to Android's 4.4 HCE mode, the FunkyGate-IP is able to get an identifier or perform a transaction over the NFC smartphone, even in screen-off mode.
(this is also an unusual selfie)

When it comes to communication with the access control system (embedded control unit or computer running an access control server application), FunkyGate-IP NFC provides an efficient, low-overhead, fully secured communication protocol using TCP sockets and AES cipher for authentication, integrity and confidentiality.

An SDK will be released soon, together with a demo of an access control server application running on a small Linux system, typically a Raspberry Pi.

The reader also embeds a tiny HTTP server that makes it possible to develop a client application in no-time using high-level languages. A simple REST API exposes the reader's behaviour (basically controlling the LEDs and buzzer) and the card/tag numbers to the outer world.

An example setup of using the FunkyGate-IP in the cloud: the reader provides data using a REST API (HTTP request, JSON content). The demo application runs in the browser (JavaScript).

An example setup of using the FunkyGate-IP in the cloud: the reader provides data using a REST API (HTTP request, JSON content). The demo application runs in the browser (JavaScript).
(click the image to enlarge)

FunkyGate-IP NFC HTTP access (REST) demo-page

Using the FunkyGate-IP NFC through HTTP: a demo-page showing how to use the REST API from a JavaScript application (if you have a FunkyGate-IP, use the demo at www.springcard.com/goto/iwm2/

First batches of FunkyGate-IP NFC (and FunkyGate-IP+POE NFC) are already shipping to our early-adopters. Don't hesitate to contact us for a demo or to evaluate the product.

New documents and the SDK will be published on our web site in the oncoming weeks. In a second step, the E663, which is the core the FunkyGate-IP NFC is built on, will be offered to developers and integrators as a versatile Ethernet-based RFID/NFC OEM module. Stay tuned !

The FunkyGate-IP is built upon the new SpringCard E663 core. Supporting Ethernet and TCP/IP, this OEM RFID/NFC module could be the basis of new generation solutions that closes the gap between contactless smartcard technologies and today's cloud architectures.

The FunkyGate-IP is built upon the new SpringCard E663 core. Supporting Ethernet and TCP/IP, this OEM RFID/NFC module could be the basis of new generation solutions that closes the gap between contactless smartcard technologies and today's cloud architectures.

.

Using SCardControl under Linux and from a Java program

SCardControl is the PC/SC function that makes it possible for the application to invoke 'proprietary' functions, implemented either in the PC/SC reader itself (CSB6Prox’N'Roll PC/SCEasyFinger or CrazyWriter) , or in its driver running on the PC, or in the PC/SC middleware.

The prototype is:

LONG SCardControl(
  SCARDHANDLE hCard,
  DWORD dwControlCode,
  LPCVOID lpInBuffer,
  DWORD nInBufferSize,
  LPVOID lpOutBuffer,
  DWORD nOutBufferSize,
  LPDWORD lpBytesReturned
);

(see http://pcsclite.alioth.debian.org/api/group__API.html for the PCSC-Lite documentation, and http://msdn.microsoft.com/en-us/library/windows/desktop/aa379474%28v=vs.85%29.aspx for Microsoft's version).

The lpInbuffer / nInBufferSize parameters hold the command buffer that will be processed by either target -reader, driver, or PC/SC middleware-.

SpringCard PC/SC Readers do provide a few 'proprietary' functions (called 'Escape commands' in the USB CCID specification). For instance, an application would send the command 58 1E 01 00 to switch the reader's red LED ON. A question remains: what must the value of dwControlCode be, when the application wants to send the command right to the reader, bypassing both the PC/SC middleware and the driver? The answer varies with the operating system, which doesn't help implementing portable code.

Differences between Windows and PCSC-Lite implementations

Windows

In Microsoft's CCID driver (http://msdn.microsoft.com/en-us/library/windows/hardware/gg487509.aspx), the dwControlCode for the Escape command is defined as follows:

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(3500)

SpringCard PC/SC Readers follow the CCID specification. SpringCard's CCID driver (SDD480) uses the same dwControlCode as Microsoft's.

Therefore, on Windows, the application would switch the red LED on this way:

#include <windows.h>
#include <winscard.h>

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(3500)

(...)

const BYTE SET_RED_LED_ON[4] = { 0x58, 0x1E, 0x01, 0x00 };

SCARDCONTEXT hContext;
SCARDHANDLE hCard;
DWORD dwProtocol;
BYTE abResponse[256];
DWORD dwRespLen;
LONG rc;

(...)

/* Instanciate the winscard.dll library */
rc = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &amp;hContext);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

/* Get a direct connection to the reader (we don't need a card to send Escape commands) */
rc = SCardConnect(hContext, szReader, SCARD_SHARE_DIRECT, 0, &amp;hCard, &amp;dwProtocol);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

/* Send the command */
rc = SCardControl(hCard, IOCTL_CCID_ESCAPE, SET_RED_LED_ON, sizeof(SET_RED_LED_ON), abResponse, sizeof(abResponse), &amp;dwRespLen);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

SCardDisconnect(hCard, SCARD_LEAVE_CARD);
SCardReleaseContext(hContext);

 

Important notes:

Working with MS' CCID driver

With Microsoft's CCID driver, the Escape feature is disabled by default.

In order to send or receive an Escape command to a reader, the DWORD registry value EscapeCommandEnable must be added and set to a non-zero value under one of the following keys.

  • HKLM\SYSTEM\CCS\Enum\USB\Vid*Pid*\*\Device Parameters (prior to Windows 7).
  • HKLM\SYSTEM\CCS\Enum\USB\Vid*Pid*\*\Device Parameters\WUDFUsbccidDriver (Windows 7 and later).

This is clearly explained in the Developer's Manual for every PC/SC reader.

Using SpringCard's SDD480 CCID driver shall be preferred.

Early versions of SDD480

Branch -Ax of SpringCard's SDD480 CCID driver uses a different value for the dwControlCode parameter.

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(2048)

Switching to the latest version of SpringCard's SDD480 CCID driver (branch -Bx and onwards) shall be preferred.

Linux, MacOS and other Unix*

In Ludovic Rousseau's open-source CCID driver (http://pcsclite.alioth.debian.org/ccid.html), the dwControlCode for the Escape command is defined as follows:

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(1)

(See http://anonscm.debian.org/viewvc/pcsclite/trunk/Drivers/ccid/SCARDCONTOL.txt?view=markup for details)

Therefore, when working with PCSC-Lite, the application would switch the red LED on this way:

#ifdef __APPLE__
#include <pcsc/winscard.h>
#include <pcsc/wintypes.h>
#else
#include <winscard.h>
#endif

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(1)

(...)

const BYTE SET_RED_LED_ON[4] = { 0x58, 0x1E, 0x01, 0x00 };

SCARDCONTEXT hContext;
SCARDHANDLE hCard;
DWORD dwProtocol;
BYTE abResponse[256];
DWORD dwRespLen;
LONG rc;

(...)

/* Instanciate the winscard.dll library */
rc = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

/* Get a direct connection to the reader (we don't need a card to send Escape commands) */
rc = SCardConnect(hContext, szReader, SCARD_SHARE_DIRECT, 0, &hCard, &dwProtocol);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

/* Send the command */
rc = SCardControl(hCard, IOCTL_CCID_ESCAPE, SET_RED_LED_ON, sizeof(SET_RED_LED_ON), abResponse, sizeof(abResponse), &dwRespLen);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

SCardDisconnect(hCard, SCARD_LEAVE_CARD);
SCardReleaseContext(hContext);

Enabling the Escape commands

With this CCID driver, the Escape feature is also disabled by default.

You'll have to edit the CCID driver's Info.plist file to enable this feature:

  • Open /usr/local/lib/pcsc/drivers/ccid/Info.plist in edit mode with root priviledge,
  • Locate the line <key>ifdDriverOptions</key>,
  • The following line is typically <string>0000</string>,
  • Define the new value: <string>0001</string>,
  • Save the file and restard pcscd.

(More details on http://ludovicrousseau.blogspot.fr/2011/10/featureccidesccommand.html)

Writing portable code

The idea is only to use a #ifdef to compile the correct value:

#ifdef WIN32
#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(3500)
#else
#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(1)
#endif

Java

The javax.smartcardio API provides Java methods that are stricly bound to the underlying PC/SC subsystem. The Card.transmitControlCommand method is the wrapper for SCardControl. The prototype is coherent:

public abstract byte[] transmitControlCommand(
  int controlCode,
  byte[] command)
    throws CardException

Now the same question: what must the value of controlCode be? The answer is short: it depends on the PC/SC stack! SCARD_CTL_CODE(3500) for Windows, and SCARD_CTL_CODE(1) for PCSC-Lite. But with another difference: the macro SCARD_CTL_CODE is not computed the same way between both systems!

 

As a consequence, the Java application must detect the OS, and compute the controlCode parameter accordingly.

Same example to switch the red LED on:

import javax.smartcardio.*;

(...)

static boolean isWindows()
{
  String os_name = System.getProperty("os.name").toLowerCase();
  if (os_name.indexOf("windows") > -1) return true;
  return false;
}

static int SCARD_CTL_CODE(int code)
{
  int ioctl;
  if (isWindows())
  {
    ioctl = (0x31 < < 16 | (code) << 2);
  } else
  {
    ioctl = 0x42000000 + (code);
  }
  return ioctl;
}

static int IOCTL_CCID_ESCAPE()
{
  if (isWindows())
  {
    return SCARD_CTL_CODE(3500);
  } else
  {
    return SCARD_CTL_CODE(1);
  }
}

static final byte[] SET_RED_LED_ON = { (byte) 0x58, (byte) 0x1E, (byte) 0x01, (byte) 0x00 };

(...)

String readerName;

/* Note that the reader's name vary with the OS too!!! */
if (isWindows())
  readerName = "SpringCard Prox'N'Roll Contactless 0";
else
  readerName = "SpringCard Prox'N'Roll (00000000) 00 00";

CardTerminal terminal = CardTerminals.getTerminal(readerName);

Card virtualCard = terminal.connect("DIRECT");

virtualCard.transmitControlCommand(IOCTL_CCID_ESCAPE(), SET_RED_LED_ON);

virtualCard.disconnect(false);

Of course this code works only if the Escape feature is enable by the underlying CCID driver, as seen above.