Web applications often involve complex interactions between the client and the Web server requiring state retention across multiple request-reply cycles. The Web’s underlying transfer protocol—HTTP [4, 7]—offers simple client/server interaction without support for state retention; state information is not retained across the request-reply cycles of HTTP. As a result, work around for this drawback has been proposed to resolve the condition of using HTTP in dynamic Web applications. Among the solutions, cookies [5] represent an attractive solution to providing state retention, allowing the Web server to “plant” state information directly in a visiting client machine.
Netscape introduced cookies in 1994, aiming to solve the state retention problem through new headers to be carried over HTTP. The current cookies specification is in RFC 2965 [5], providing a server-side-initiated approach to creating a stateful session with HTTP. Cookies are small bits of textual information a Web site might send to Web browsers to be stored within the client machine and returned unchanged in subsequent visits to the site. The ability to store cookies on the machine enables the Web server to track state information while interacting with a browser across a session. The cookies can be kept past a session, so when users power off their machines the state information is retained and can be used again the next time they visit the site that first created it. Properly designed, cookies remember user activities on the Web site and provide additional functionality to the user. An example of such functionality is keeping user information in a cookie and customizing pages during subsequent visits. For example, Microsoft’s Hotmail Web site uses this approach to remember user preferences for displaying information and hence provides customization without a database server, thus offloading the workload to user machines.
Despite the widespread use of cookies as a basis for Web applications that keep state information, they also present a number of unresolved design issues [5, 6]. Cookies state information (stored on client-side memory by the Web server) is inherently tightly coupled to individual machines. However, many Web applications (such as banking, online shopping, and e-auctions) use cookies as a basis for identifying user preferences and identification. As the user moves to different machines to access the same site, the information previously recorded is lost. The Web application has no way to restore the state, unless the user revisits the same client machine to which the original cookies were sent. Storing cookies on a machine also involves security risks; cookies information stored as plain text files is easily accessed, viewed, modified, and deleted. The situation is made worse in a single-user PC system where the browser lacks access control to distinguish among the machine’s various users.
Here, I present a novel solution to making the cookies “mobile” by leveraging smart cards with the benefit of mobility in the user’s pocket. The CookiesCard framework uses a smart card as a secure, mobile storage medium for managing personalized cookies. The CookiesCard proxy interacts directly with the card to provide cookies management while functioning as an intermediatory between the client browser and a Web server. In addition, the proxy filters out any third-party cookies used to track personal Web-surfing behavior.
Personalization and Mobility
Cookies provide a general mechanism for Web sites to maintain state information across multiple HTTP request-response cycles. The robustness of cookies for retaining state, even across multiple sessions, has motivated the use of cookies for capturing the personal information needed for personalization based on individual user profiles [6]. For example, Web sites like Amazon.com retain user profiles in the form of cookies that represent an index to a back-end database. The database pointed to by the cookies contains important information on user preferences, shipping addresses, past transactions, reading interests, and more. This is often a desirable and convenient service for end users, enhancing their surfing experience at sites with personalized Web pages targeting specific user interests and profiles. At some sites, cookies store such personal information as user login identification and passwords. With the identification information stored on a client machine, the Web application is relieved of responsibility for maintaining the server-side user-access-control database.
Release of Netscape Communicator source code to promote open source development of the Mozilla browser project makes it an ideal candidate for developing CookiesCard over the browser’s platform.
Using cookies to capture personalized information maintained on a client machine seems to be a reasonable and convenient solution for users on fixed machines where the cookies directly associated with the user are tightly coupled to the machine. However, such an assumption is invalidated once the user interacts through another machine, perhaps a public machine, where cookies capturing personalized information are lost.
Using cookies to maintain personalized information is complicated by two main design issues:
Machine dependence. The concept of cookies being stored on a client machine is mismatched with personalized cookies when the cookies are tightly coupled to (frequently mobile) individuals. Cookies are written to persistent storage as disk files in the computer. In a single-user operating system, the cookies are shared among all users of the computer, and no differentiation among the cookies is maintained. This issue is not a factor in multi-user operating systems, where cookies are maintained separately based on the associated login user account. In either situation, maintaining personalized cookies on a machine is complicated by cookies mobility when users move from computer to computer.
Security and privacy. Many users simply want to get rid of cookies stored on disk that leave a persistent record of the Web sites they’ve visited. This is particularly sensitive when the user operates on a public machine where cookies associated with specific individuals are potentially exposed and can be read, copied, and modified by other users. The ubiquity of the Web as an information- and commerce-delivery platform, coupled with the benefits of cookies for state retention, motivates the need to manage “mobile” cookies tightly coupled to individuals. Cookies should be mobile-enabled, so personalized information is retained and deployed across different client machines.
Smart Cards
Smart card technology represents a new computing environment based on embedding processing elements on a credit-card-size platform [2]. It offers the benefits of mobility and the ability to store large amounts of information compared to magnetic-based plastic cards. More important, smart cards with local processing capabilities facilitate development of programs for securely managing sensitive personal cookies information [2]. In order to access and probe data stored on smart cards, the card holder might be required to enter a personal identification number (PIN) that prevents unauthorized access to sensitive information. A built-in processor enables the card to authenticate the PIN before data is released to the external application hosted by a workstation or PC.
Application development. Until recently, most smart card-supported applications targeted specialized domains and ad-hoc systems, with little or no integration with mainstream information systems. One inhibiting factor was the fact that smart card technology, unlike, say, PCs, lacks a good operating system and development environment [1]. The art of developing a service application on a card often requires programmers to have in-depth knowledge of the internal architecture and programming primitives of a particular card. The lack of a common architecture and open programming interface resulted in only ad-hoc implementations of smart card systems that are not interoperable while being difficult to develop.
Building on the same interoperable spirit as the original Java language, Sun Microsystems developed the so-called Java Card [2] programming architecture for smart cards to facilitate the concept of “write once, run on all cards.” The idea of building a lightweight Java virtual machine (JVM) around the processing architecture allows the programmer to develop applications on smart cards using familiar Java language and programming paradigms. The Java Card’s JVM hides the card manufacturer’s proprietary technology with a common system interface.
Application protocol. While Java Card resolved the issue of how to provide a common programming interface for developing smart card applications, the communication between the card’s applet (not to be confused with Web browser applets) and the host terminal is nonstandard and often ad hoc in nature. An application typically includes both on-card and off-card applications [2]. An off-card application, residing in the host terminal, constantly communicates with the on-card application via the card terminal reader. To standardize the communication protocol between the off-card program and the on-card application, ISO has sought to define the standard known as ISO/IEC 7816 [3], which includes command messages and response formats returned by the card. The unit of transfer between these messages and response formats is the “application protocol data unit,” or APDU. Figure 1 outlines the communication flow between an off-card program and an on-card application via the terminal card reader.
Using this approach to develop smart card applications requires a detailed understanding of a particular card’s command set and how to construct primitive APDUs for exchanging messages and responses. Java Card software provides classes for constructing and parsing these primitive APDU messages. However, the fact remains that the off-card program and the on-card application communicate in a nonstandard byte format that is often unstructured and ad hoc in nature [1].
CookiesCard Architecture
Besides wanting to decouple cookies from a client’s machine and support their mobility, an important requirement in developing CookiesCard has been the need to avoid reengineering existing technology infrastructure. In light of the privacy and security issues posed by cookies, most modern browsers, including Netscape and Microsoft Internet Explorer, include some form of cookies management options that allow end users to set policies, preferences, and options for managing cookies on their machines [6]. Which policies are available is often dictated by the browser’s developer, who might not have provided adequate options for managing and controlling the flow of cookies. One approach in CookiesCard is to extend and modify the existing browser design to support the mobility of cookies across different machines.
A CookiesCard-enabled browser must be able to perform cookies management in tandem with the smart card’s applications to provide effective control over the influx of cookies. Release of Netscape Communicator source code to promote open source development of the Mozilla1 browser project makes it an ideal candidate for developing CookiesCard over the browser’s platform. Though feasible, this approach may also significantly restrict the portability of CookiesCard across heterogeneous system platforms and browsers.
An alternative is to develop the CookiesCard architecture based on a proxy server approach [1]. The proxy server represents a local server between an existing client browser application and a remote Web server where it is responsible for intercepting all client HTTP requests to the designated Web server. The request headers are parsed to locate Cookie headers, if any are present. The proxy server is similarly responsible for capturing the returning Web server’s HTTP responses to the client browser. The proxy is responsible for locating and extracting the cookies from the response headers by identifying the SET-COOKIE header. The proxy server architecture provides a unique method and opportunity for adding services to an end-to-end client/server Web computing application.
Since all cookies are intercepted and managed by the proxy, the client browser is effectively freed from having to manage the influx of cookies, thereby decoupling them from the client’s machine.
The proxy server architecture provides two main benefits:
- Enhanced performance through service extension. An intermediary server can be inserted between an end-to-end client/server computing model. The server may be configured to add service to the computation without having to change the underlying HTTP protocol. An HTTP cache proxy is an example of such a service, whereby requests and responses are intercepted and cached on local memory. Subsequent requests for the same Web objects may be served directly by the cache proxy, instead of the real server.
- No modification to client and server. A significant benefit of the proxy architecture is that the protocol served between the client and the server requires no modification, representing relatively easy deployment of enhanced services to existing computation.
CookiesCard uses of the proxy architecture to provide a cookies management facility based on a smart card. The CookiesCard’s proxy intercepts and parses all HTTP requests and responses to facilitate cookies management on the proxy and the smart card. Cookies set by the server are captured transparently by the proxy and stored locally. Conversely, requests destined for URL sites associated with cookies are appended with the cookies to be returned to the server. Since all cookies are intercepted and managed by the proxy, the client browser is effectively freed from having to manage the influx of cookies, thereby decoupling them from the client’s machine.
Architecture and Implementation
In the system architecture of the CookiesCard framework (see Figure 2), the proxy server, running on the same host as the Web browser, acts as an intermediary for capturing and processing HTTP requests and reply messages transversing between the browser and the Web server. It communicates to the card applications via standardized APDU messages.
The Proxy Server consists of two modules: the Interceptor and the Off-card Cookies Manager. The former is responsible for listening for HTTP requests (solid arrows) arriving from the Web browser and the corresponding responses coming from the Web server. On receipt of an HTTP request, the server parses the request and checks with the Off-card Cookies Manager cache on whether cookies destined for the URL site are to be appended. Similarly, on receipt of an HTTP response message (dashed arrow) from a Web site, the Interceptor parses the response headers for Set-Cookie primitives, extracts any cookies from the header, passes them to the Off-card Cookies Manager, and returns the remaining response contents to the Web browser. The Off-card Cookies Manager is responsible for managing the cookies cache and processing cookies from the HTTP response.
To accelerate the searching and updating process, the module implements the CookieHash class that manages the caching of cookies in main memory. As its name implies, it is implemented through a hierarchy of hash tables that first map the domain key to the entry in the path hash table. The value mapped to the path key is a vector holding the cookies that are valid for the corresponding domain and path; the logical structure of the CookieHash class is outlined in Figure 3. In addition, the Off-card Cookies Manager functions as a host interface to the smart card’s applets via APDU messages, providing user access control, cookies uploading, and cookies updating on the smart card storage media. To minimize storage space, all cookies stored in the card are text-compressed using the direct Huffman coding scheme.
The card itself consists of four modules, each implemented as a JavaCard applet class. The Access Control applet is responsible for processing APDU messages containing PINs input by users when they first insert their cards into the reader. The PIN is extracted by the applet and compared against the stored PIN. Once authenticated, the Off-card Cookies Manager communicates with the other applets on the card. As part of the security feature, a configurable maximum number of retry counts can be set. For each time a PIN is entered incorrectly, the retry count is decremented. When the count reaches zero, the applet permanently blocks access to the card’s contents, so it no longer communicates with off-card applications.
The Storage Manager applet implements file system storage to store cookies and a cookies management configuration file. Although the smart card file system is defined in ISO7816-4, it is specified as a low-level hierarchy-based file system organized into a collection of three elementary file types: master, dedicated, and elementary. The main function of the Storage Manager is to organize these low-level elementary file types as an object-based file system abstraction.
The On-card Cookies Manager applet is responsible for managing the storage and indexing of the cookies based on the domain and path names that set the cookies. The Cookies Storage applet provides an object-level abstraction of the cookies to enable robust manipulation and processing of cookies information.
The CookiesCard proxy program is implemented on a Java platform, supporting true portability across heterogeneous systems. In addition, the OpenCard Framework (OCF) [2] provides a vendor-independent framework for developing host-side applications. The OCF supports 100% pure Java smart card applications matching the requirements and objectives of CookiesCard. On the smart card side, the Java Card software development kit is used for portable smart card applets on the GemXpresso 211PK smart card from Gemplus Gemplus International S.A. (www.gemplus.com). CookiesCard has been tested on several popular Web sites involving complex interactions among its various components.
Conclusion
The design and implementation of the prototype CookiesCard demonstrates the benefits of managing cookies on a smart card. Users “carry” their personal cookies on the card, promoting security and avoiding privacy intrusions. Cookies are coupled to users, not to machines. CookiesCard employs a proxy architecture as an intermediary between the Web and a smart card. The proxy captures transiting cookies and manages them, along with the user’s card, which represents a secure storage medium by requiring the user to submit his/her PIN to verify cardholder identity. A prototype system to test and validate the concept was implemented on a Java platform for the proxy, using Java Card on the smart card.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment