Abstract

In order to provide secure authentication that is actually adopted by users, there is a need to provide building blocks that enable Web developers to leverage mechanisms that are superior both in terms of usability and security when conducting transactions using a Web browser as the user agent to connect to the Internet.

Given that there are multiple proposals, products and approaches to the problem of identity in the browser, this paper is deliberately narrowly focused on the basic building blocks that are required to use smart cards as identity devices in Web based interactions. Ideally, browsers should evolve to include a standardized API providing local hardware access to the card. On top of that capability a JavaScript library can provide simplified access for the Web developer and potentially a server component can take care of back end cryptographic operations so developers can adopt the technology easily.

Introduction

When addressing an audience who participate in cryptography workshops, there is little need to highlight the security risks posed by that the use of passwords as the main credential to authenticate users to Web sites. However, the prevalence of passwords and the fact that many Web site operators surrender to their user is a testament to the path of least resistance that they represent in order to attract users to the service.

With the rapid growth of utility computing, this problem will only become more prevalent as most service providers can’t afford the luxury of closing the door to users who want to use the service and are not fully aware of the implications of using passwords.

In order to encourage adoption of better alternatives, players in the industry should work together to facilitate the adoption of those alternatives by end users, by presenting a user experience that is even simpler than that offered by passwords; but also by developers, by empowering them with simplified APIs that make the use of cryptographic devices ultimately easier than supporting passwords in their Web sites.

This paper proposes some basic building blocks that can serve as the foundation for adoption of cryptographic smart cards for user authentication in the Web and extends an invitation to other players to collaborate in the refinement and integration of these blocks for the benefit of the industry.

A Parallel with Dynamic Pages

Modern Web sites offer user interfaces that go well beyond the basic rendering of pages of the early days of the World Wide Web. In particular, the ability to load content in the background without having to reload the full page has paved the way to user experiences that are in many cases superior to those offered by native applications. And this is possible despite, or probably thanks to, developers having to target different browsers in different platforms.

The interactivity and responsiveness of Web sites that users take for granted today are not that difficult to implement by Web developers who can leverage rich frameworks like jQuery that simplify the details of making a page interactive in a variety of target browsers.

However, when looking at the building blocks involved, there are a few key components whose appearance made all this possible. At the origin of it, there is the XMLHttpRequest object that was designed by Microsoft and adopted by Mozilla, Apple, and Google, taking care of the actual data exchange with the server. On top of it, a framework like jQuery offers an added level of abstraction for browser differences and presents developers with an expressive and consistent API. Once these blocks are in place, it becomes much simpler for the Web developer to add an interface scaffolding component such as Twitter Bootstrap of Zurb Foundation and build highly interactive Web applications.

Smart Cards in the Browser

Using smart cards inside from a Web page is something that has been attempted with varying degrees of success but it has usually be an effort driven by a vendor interested in supporting a specific type of card, reader or use case. Furthermore, the low level APIs to access smart cards are by no means universally adopted. Windows has a quite stable implementation of the PC/SC framework but that is unfortunately not the case of other major operating systems. And with the advent of NFC, some alternative APIs have emerged that focus more on abstract representation of NFC messages rather than low level binary exchanges with the cards.

The main impediment to using a credential in a smart card to authenticate users is of course the fact that the browser does not have access to the local hardware device where the card is connected. Our suggestion is to adopt a minimalistic approach where an object that will ultimately be a JavaScript object available to the Web page provides just the functionality required to enumerate available readers, fire events when cards are connected or disconnected from the reader and exchange low level Application Protocol Data Units APDU with the card.

Using a pattern similar to the XMLHttpRequest object mentioned previously, this would initially be a custom component packaged as an ActiveX control for Internet Explorer or as an NPAPI plugin for other browsers. In the long term, an external component approach is not sustainable as browsers start dropping support for this type of extensibility mechanisms that are also not available in mobile platforms. As adoption takes hold, it would be preferred if browsers incorporate natively this functionality and the discussion rather shifts to new problems like what low level APIs to support, for example continue to support PC/SC or explore alternatives like direct USB access to CCID class devices.

Once the basic bridge between the hardware reader and the Web page is there, an expressive JavaScript API is built around it to ensure that a web developer can easily incorporate smart card functionality just adding a single script file, as it is done with jQuery. Part of the value offered by this layer is the ability to continue to evolve the underlying hardware interface component without breaking compatibility with what developers would have implemented already.

Cryptographic Capabilities

Smart cards provide two basic functions in the context of user authentication. First, they are portable containers of user identification and profile data such as an email address or even demographic data in the case of a document like an electronic passport. Second, they provide an isolated computing environment for the creation and use of cryptographic keys.

To effectively use the cryptographic capabilities of smart cards, it is necessary to simplify for Web developers the process of creating and managing keys. More importantly, the use and adoption of smart cards is more justified in the context of enterprise applications than consumer applications. In enterprise situations the whole point is that user enrollment and card issuance is managed by a different system that the application leveraging the identity credentials.

In order to abstract the problem of key distribution, the third building block of the solution is a back end server that manages the messaging protocol with the card in order to retrieve contents or authenticate the card by means of cryptographic protocols and present just authenticated data to the Web developer.

Conclusion

Using a smart card for authentication provides a superior user experience since a physical credential makes explicit the use of the credential reduces user confusion about credentials being compromised. At the same time, a physical card works better in environments like the enterprise where the credential is actually managed by the issuer to represent a delegated authority for the user to access company resources.

Rather than trying to solve all issues related to identity management and propose a new set of protocols to complement what is being discussed by the community already, we propose that by integrating a simple mechanism to access smart cards from the browser it would be possible to start gaining traction with developers and an ecosystem to facilitate the use of cryptographic smart cards for authentication will prosper with input from different interested parties. With the interest to contribute to the Internet community building support for smart cards in the browser, we would like to demonstrate our approach to the participants of the workshop.