921087 - Feature request: interface to Smart Cards

Status: RESOLVED DUPLICATE of bug 1294514

(Core :: DOM: Device Interfaces, defect)

Description

[Francois Grieu]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

Example use case: User of public transport, on a network using Smart Cards as mean of payment / allowing entrance, purchases weekly pass and write it on her Smart Card from the comfort of home, with a cheap Smart Card reader connected to the PC, using some web application.

Currently such web application typically uses JavaScript, talking to a browser plug-in (or ActiveX), that interface to the Smart Card reader through PC/SC stack. Examples of such solutions:
<http://www.sconnect.com/FAQ/index.html#compatibility>
<https://github.com/ubinity/webpcsc-firebreath>

Wanted: an interface bridging the web browser to Smart Card gap, no depending on a plug-in.

State of the Smart Card interface world: most recent add-on Smart Card readers are conforming to PC/SC specifications, natively (e.g. using the USB CCID class and a standard OS-supplied driver) or using a manufactured-supplied driver.
That makes these readers usable from the C API defined in header winscard.h, which provides good independence from the Smart Card reader, and fair portability across OSes (Windows, Windows CE, OS X, Linux, other Unix). That standardizes discovery and binding to connected Smart Card readers, discovery and binding to inserted Smart Cards (both contact and contactless), and exchange of data with the card. Various interfaces to higher-level language or applications are typically written on top of winscard.h; any other route is insurmountably uphill IMHO.
This winscard.h API consists of declaration of C functions with names starting in SCard, like SCardConnect. Documentation lives at Microsoft, e.g.
<http://msdn.microsoft.com/en-us/library/windows/desktop/aa379473%28v=vs.85%29.aspx>
Outside Windows, winscard.h is available from the PCSC-lite package at e.g.
<http://pcsclite.alioth.debian.org>

That winscard.h API is suitable, or at least bearable, for a local application written in C (or a language with direct binding to that). It is not directly suitable in a browser, lacking at least:
1) An object-oriented interface to the aforementioned features of winscard.h, automagically handling resource de-allocation, preventing buffer overflow, and adapting to the language's practices (e.g. exceptions).
2) Arbitration of what is allowed to access Smart Cards readers and their cards. The last thing we want is that any random website could perform arbitrary actions on any card connected to the PC (e.g. presenting a random PIN to a bank Smart Card, destroying it). That's probably the hardest thing to organize, as anything involving trust.

If we look at what exists as popular API featuring this, one of the most visible is the javax.smartcardio API, available since Java 6. That is documented by Sun/Oracle, here:
<http://docs.oracle.com/javase/7/docs/jre/api/security/smartcardio/spec/javax/smartcardio/package-summary.html>
In addition of the above 1/2, javax.smartcardio supplies some less needed features
3) harmonization of APDU exchanges, abstracting some differences in the underlying protocols
(note: an APDU is an elementary command to a Smart Card; due to a limitation of the ISO 7816-3 T=0 protocol, used by many contact Smart Cards, if an APDU conveys data in both directions, it is subdivided into two APDUs, in a mostly standardized manner; this glue layer is missing from winscard.h)
4) An object-oriented interface to logical channels
(note: some Smart Cards can handle multiple concurent tasks thru multiple logical channels going thru the same physical interface).


About CT-API: IMHO that is a legacy technology, obsoleted by PC/SC, with little adoption compared to winscard.h or javax.smartcardio outside of Germany (Deutsche Telekom was instrumental in the development of CT-API). Specifications are there
<https://www.tuvit.de/cps/rde/xbcr/tuevit_de/CTAPI11EN.pdf>
Among it drawbacks: CT-API does not sit on top of a device-manufacturer-neutral interface (like winscard.h implementing PC/SC is). Far from all readers come with CT-API. The scope does not include a mechanism to enumerate installed readers. AFAIK an application programmer can not use a CT-API card reader without incorporating some executable coming from the manufacturer of that card reader (although there is now some generic CT-API implementations binding to winscard.h). Above 1/2/3/4 are out of scope.

	
Some Intellectual Property considerations:
- The PC/SC specification was written by a consortium for the purpose of wide adoption. Manufacturers of PC/SC devices (but not programmers using these) have to agree to some legalese, but there is no fee; and the legalese seems to be about neutralizing any patent rights manufacturers may have. The PC/SC specification can be downloaded without restriction from
<http://www.pcscworkgroup.com/specifications/specdownload.php>
- The de-facto API to PC/SC is winscard.h, which originated from Microsoft, and is not defined in the PC/SC specifications. The Smart Card industry has been using this API (in the sense of the name of C functions, parameters, and behavior) for like two decades, without annoyance from anyone, across multiple platforms. The implemenration of this API in Windows is proprietary. Elsewhere, the dominant implementation is the open-source PCSC-lite.
- Not available: status of javax.smartcardio as an API, and of its published implementation(s) on top of winscard.h

Comment 1

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

We do have plans to add Smart Card API, but it will be implemented on FirefoxOS first.

Comment 2

[Benjamin Smedberg]

Yoshi, this is a relatively high-priority item for desktop Firefox so that we can convert websites off of the Java smartcard interfaces. Please keep me in the loop so that the desktop implementation is not accidentally shortchanged; are there bugs or other public documents on the current plans?

Comment 3

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Hi, Benjamin
I haven't filed bugs yet, but once I have, I'll CC you in the bugs.

Currently I am still checking the support from the modem, as the access to UICC is done through modem. (Or RIL requests). See Bug 921320.

Also there is a bug, Bug 879861, is discussing Secure Element API.

thanks

Comment 4

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Related to FxOS which is dead, but marking as a duplicate of WebAuthn as that's kind of our aim with that API.