![[image]](Image3.gif)
The N*Able Reader-Side Software Architecture
N*Able Technologies, Inc. develops hardware and firmware for intelligent, secure smart card readers. These secure readers can be attached to a PC as a standalone unit or as an integrated keyboard, and provide a completely self-contained environment, firewalled from the potentially insecure PC, for protecting sensitive data stored on a smart card (such as personal information like account numbers, passwords, private keys, and so on), or memorized by the user (such as a PIN). Firmware applications execute entirely within the secure environment of the reader, allowing for tamper-proof execution of high-value security functions.
The secure smart card reader uses the N*Able N*Click security coprocessor, integrating a 32-bit RISC engine with smart card controllers, cryptographic functions, host (PC) interfaces, and embedded software in flash memory which can be updated using a secure field update protocol.
Additional software running on the PC—standardized smart card interface software such as PC/SC, electronic commerce applications such as SET, or custom applications that use the N*Able API—can be used to interact with the secure reader to retrieve information from the smart card, verify an identity based on information on that smart card, or perform other operations requiring a high level of security or authentication (or both).
This paper describes the overall software architecture of the embedded firmware in the N*Able secure smart card reader itself, of the PC(host)-side software and how it communicates with the reader, and provides an overview of the field update protocol used to securely update the software on the reader.
The explosion of the Internet and of distributed computing environments such as intranets and virtual private networks has brought about enormous changes in how companies and individuals communicate, shop, and do business. But with enormous new opportunities have come enormous new risks, particularly in the field of computer and network security. It is easy to protect personal or company data or to verify someone’s identity when a computer system is locked inside your own building and isolated from the rest of the world, or when you are running your own closed network from end to end. It is much more difficult to protect that data when your system may be communicating with other computers you do not control and cannot trust, at sites potentially thousands of miles away, connected by a public network on which anyone may be listening.
The N*Able secure smart card reader, in combination with smart cards, is designed to solve these security issues problems by securing data and verifying an identity at its source: on the user’s PC.
Much of the focus on Internet security, particularly for electronic commerce on the World Wide Web, has been in securing the network connection between a client PC and an Internet server. The SSL (Secure Sockets Layer) protocol, built into Web servers and browsers, encrypts the data transmitted over a TCP connection to ensure a secure transaction. IPsec, a protocol for encrypting network connections at the IP level, works similarly for routers and bridges to encrypt all network traffic between two points for environments like virtual private networks.
While the network connection between PC and server is the most obvious point of attack from a security standpoint, there are other significant points at which sensitive data could be snooped, spoofed, or altered. Once sensitive data arrives through a secure connection to a server at its destination, for example, the administrator of that server must then store the data in a protected way —behind a secure firewall, or on a system off the Internet to prevent that data from being stolen or snooped by attackers ("crackers") who might manage to break into that server from the Internet.
Even before the data leaves the user’s PC itself, viruses, worms and Trojan horse software can find its way far too easily onto that system, either through an actual system break in (the cracker again), or through more subtle means such as an email attachment or virus-infected file downloaded off of the Web. Once attack software is loaded onto a user’s PC, it can quietly wreak havoc on an unsuspecting user—listening for interesting information the user may be typing, changing the information a user receives to deceive the user, or pretending to be an application the user trusts in the first place.
In fact, given a secure network connection with SSL or IPsec, and a security-knowledgeable system administrator to protect the data on the server end, it could be argued that the PC—anonymous, uncontrollable, generally used by a less-experienced or less-knowledgeable user—is in fact the weak link in the security chain.
If the user’s PC cannot be trusted, the solution to the security problem is to isolate (firewall) sensitive data as well as operations performed on that data from the PC and its operating system. The N*Able secure smart card reader works in precisely this way, through the use of the secure environment provided by the secure reader, the interaction between the host PC and the reader, and the smart card itself.
The secure N*Able smart card reader contains a 32-bit RISC co-processor chip (currently the N*Click), which includes smart card controllers, cryptographic functions, host (PC) interfaces, and embedded software stored in flash memory. It is typically built into a keyboard or as a separate reader unit and connected to the PC through a standard PS/2 or USB connection.
The PC communicates with the secure reader using a defined set of commands to request data from the smart card or run applications on the reader. Because the smart card reader is an independent unit of the PC with its own processor and memory, and applications run entirely within that unit, nothing on the PC can interfere or contaminate the reader's secure environment. The N*Able secure smart card reader provides a virtual firewall between the untrusted PC and the secure information on the smart card.
The N*Able secure reader can also function as a traditional ("non-intelligent") smart card reader. It supports the PC/SC protocol for accessing smart card functionality from Windows applications. Extensions to PC/SC, however, can provide functionality for securely entering unlocking PINs for smart cards (see the section on Secure PIN Entry for details).
The smart card is a standard chip-based ISO 7816 card on which can be stored simple data such as credit card numbers all the way up to and including digital certificates, public or private keys and encryption software. Because of the sophistication of the secure reader, however, the card itself does not have to be all that "smart." Cheaper signing-only smart cards can be used in conjunction with N*Able applications rather than more expensive multi-function cards.
Because sensitive data is stored on the card, and not on the PC, the card can be removed from the reader and carried around, or potentially used in multiple N*Able secure readers, ATMs, point-of-sale terminals or any other smart card devices that support the data on that card.
The N*Able secure smart card reader consists of the N*Click secure processor, a smart card socket, and embedded firmware (software) stored in flash memory. In this section we'll look at the architecture of the secure reader's environment, which consists of roughly six layers:
All the software layers above the N*Click co-processor are stored in reader flash memory, and can be updated or replaced altogether using the N*Able field update protocol. See the section on Field Update for details on this protocol.
The N*Click secure co-processor is a 32-bit RISC processor that drives the N*Able secure reader. Full details on the N*Click architecture can be found in the N*Click Hardware Reference Manual.
The N*Able reader software architecture builds on several core features of the N*Click processor, including :
N*Able’s real-time OS is a custom OS based on Embedded System Products’ RTXC real-time OS version 3.2. The Core RTXC OS provides:
On top of the RTXC, N*Able has added functionality specific to the N*Click hardware, including:
The device driver layer provides access to hardware features in the N*Click processor and for I/O functions to the smart card reader, the keyboard, and the host.
Between the device drivers and application layers lie two abstractions for handling messages to and from the reader to the host: a message I/O abstraction layer, and a host I/O abstraction layer. Message I/O is "above" the Host I/O.
The message I/O abstraction layer manages messages from the host to the reader, ensuring that the correct application is called with the correct commands and data, and also managing output back from that application. The message I/O layer could be considered a message "switchbox," accepting generic messages from the host and then determining (from the content of those messages) which application is to accept that message, and then passing it along.
The Host I/O layer, in turn, provides an abstraction for the various host input drivers (USB, PS/2, RS232) for application messages to be sent back to the host. In this way the reader-side application does not need to know on which interface the reader is running.
The topmost level of the N*Able software architecture contains applications and libraries that drive high-level functionality on the N*Able secure reader. Applications and libraries may include:
Additional applications or libraries may be available on the reader through the use of field update. See the section on Field Update for further details on the update protocol.
The library for LCD internationalization provides a mechanism by which messages sent to the LCD ("Insert Card," "Enter PIN," and so on) can be displayed in different languages. The default language is automatically determined through host-side localization of the reader. All other libraries and applications that display messages on the LCD use this library.
X.509v3 is a standard for defining the structure of digital certificates. The X.509v3 certificate library handles all operations concerning digital certificates, including decoding and verifying the signatures, validity dates and extensions for individual certificates and certificate chains.
The library includes a certificate cache which can be used to store already-verified certificates. If a certificate is already stored in the cache, the library does not need to re-verify the signature on that certificate. Keep in mind that because the certificate cache is stored in the secure environment of the smart card reader, it cannot be tampered with or attacked.
The X.509 certificate library uses the cryptographic functions in the device driver levels and N*Click co-processor, as well as the ASN.1 library. It can be used by any applications that need to make use of certificates as part of their own operation.
ASN.1 (Abstract Syntax Notation) is a formal language for describing data structures of various types. DER (distinguished encoding rules) is a specific format of ASN.1 most commonly used for cryptographic applications such as digital certificates. The ASN.1 DER library in the N*Able secure reader is a particularly small and memory-efficient ASN.1 implementation that allows the encoding and decoding of DER-encoded ASN.1 objects.
The ASN.1 DER library is used by the X.509v3 certificate library and the N*SET application. It can be used by any application requiring ASN.1-encoded objects.
The PC/SC specification provides a standardized mechanism for using smart card technology from within Microsoft Windows operating systems, by defining a basic set of APIs which can be used to send messages to a smart card reader. The PC/SC library allows the N*Able reader to be used as a standard non-intelligent PC/SC-compliant smart card reader.
Note that because PC/SC applications run on the host PC's untrusted environment, they cannot take advantage of the secure features of the N*Able smart card reader. The security of PC/SC applications can be enhanced, however, with the use of Secure PIN Entry (SPE). SPE allows unlocking PINs for smart cards to be entered and preserved entirely within the secure environment of the reader, preventing the host PC from using port sniffers or software to eavesdrop on that unlocking PIN. See the section on Secure PIN Entry for details.
EMV (Europay MasterCard Visa) is a standardized framework based on ISO7816 to enable smart cards to be used for electronic payment systems such as ATMs, cash registers, or point-of-sale terminals. In addition to the secure smart card features of the N*Able secure reader itself, the EMV services library allows the N*Able reader to act as an EMV terminal, to accept EMV-enabled cards, and to handle messages from EMV-enabled applications.
EMV uses the ASN.1 library and is used by N*SET (for EMV-based SET transactions).
SET (Secure Electronic Transactions) is a specification developed jointly by MasterCard and Visa for processing credit card or electronic payment transactions over the Internet securely. SET uses digital certificates, authentication and encryption to provide a payment framework that is secure and private for the consumer, the merchant, and the bank that issues the card.
N*SET is an extremely small and memory-efficient implementation of the SET specification inside the N*Able reader that allows the reader to support SET transactions with or without the use of a smart card. Because the N*SET software executes entirely within the secure environment of the N*Able smart card reader, all SET operations (cryptographic operations, decoding and encoding of SET messages) are also executed inside that secure environment, and are much more resistant to tampering and eavesdropping than a standard PC-based SET implementation.
The N*SET application uses the LCD library, the X.509v3 library, ASN.1, EMV, and the Message I/O abstraction layer.
The N*Able secure smart card reader must be connected to a host PC, and applications on the PC invoke applications on the reader. This section describes the host-side architecture and how the PC interacts with the secure reader.
The N*Able secure smart card reader can be connected to the PC in a variety of configurations—embedded in a peripheral device such as a keyboard (via a combination PS/2 and RS232 interface, or USB), or as a stand-alone unit (either RS232 or USB)
N*Able supports host-side drivers for each of these interfaces (USB, RS232, PS/2) for Windows 95/98, Windows 2000, and Windows NT.
PC-side applications that make use of the N*Able secure smart card reader currently run only on Microsoft Windows operating systems. However, the host-side architecture for N*Able applications makes use of platform-independent COM objects communicating with a platform-specific device service, which allows for extensions to other platforms in the future.
Currently on Windows, applications communicate through a COM proxy to the N*Able Device Service and the Microsoft Smart Card Resource Manager (PC/SC), down through device interfaces to the smart card reader.
Messages to the reader's software environment include the name of the reader-side application, the command that application is to run, and any other data that application needs to run that command. The Message I/O layer in the reader software interprets that message and invokes the appropriate reader-side application with the command and data.
In addition to N*Able-Compatible applications, standard PC/SC applications can also make use of the N*Able smart card reader. PC/SC applications use the standard PC/SC API calls, which are also interpreted through the message I/O on the reader side and then sent directly to the PC/SC application in reader software for execution. Note that PC/SC-based applications run entirely on the host-side PC (except for the simple PC/SC command application on the reader) and therefore cannot take advantage of any of the secure applications or features in the N*Able smart card reader.
Normally, because standard PC/SC applications run on the untrusted PC and its untrusted OS, those applications cannot take advantage of any secure features of the secure smart card reader. N*Able's secure PIN entry allows this basic functionality of PC/SC applications to be securely enhanced for smart cards that use unlocking PINs.
Smart cards that use PINs protect their own data through the use of the PIN, which provides extra security for the data on the card by requiring the user to memorize that unlocking PIN. The PIN is submitted to the card and the card itself makes the determination whether or not the PIN is correct. After the card has been unlocked, the application can access the data on that card.
In a standard PC/SC application, when an application requests the user to enter their PIN, the PIN characters are sent from the keyboard to the host PC and back to the reader again before being submitted to the card—and anywhere in that chain the PIN could potentially be trapped and stored for later use (so-called replay attacked) using software or a port sniffer.
Secure PIN entry is an API for PC/SC applications that allows the N*Able secure smart card reader to trap the user's keystrokes within the secure environment of the keyboard or stand-alone reader. Those keystrokes are then sent directly to the card without having to detour through the untrusted environment of the PC.
The Secure PIN features of the secure reader can be accessed through a Secure PIN API on the host side. By calling the Secure PIN API from a PC/SC application, the reader enters into secure PIN mode, and the key LED on the reader blinks. This indicates to the user that the keyboard or reader is retaining their keystrokes and that it is safe to enter their PIN. Users should be trained to recognize the difference between entering a PIN when the key LED is blinking (safe to enter the PIN) and not blinking (unsafe to enter the PIN).
Note that after the PIN has been submitted to the card and the card has been unlocked, secure PIN entry provides no future secure features for the data on the card; PC/SC applications running on the host can use any standard mechanisms to access the data on that card after the card has been unlocked. Only applications that run within the secure environment of the reader itself can protect the data on the card from the untrusted PC.
Secure Applications are applications that use the host-side N*Able application API and the N*Able smart card reader to provide a secure execution environment for a user's data and for the operations that are performed on that data. Because the user will often be unaware of precisely where his or her code is actually being executed, it is necessary to provide visual cues both on the PC and the reader side to that spoofing attacks (modified software, attempts to trick the user into entering data in an insecure environment, and so on) can be prevented. N*Able recommends the following two mechanisms for indicating secure applications:
The combination of both the key icon in the application and the key icon in the LCD allows the user to recognize when their data is protected from possible attack. If a malicious non-secure application added the secure icon to their windows to trick the user into thinking that their application was secure, the corresponding key icon would not appear in the LCD, and the user would know that something was wrong. The converse—forgetting the key icon on the host side, but using secure applications on the reader side—is obviously less of an issue, security-wise, but the key icon in the host-side application is an important visual indication to the user that they should wait for the LCD to confirm that the reader has entered secure mode.
All of the embedded software contained on the N*Able secure smart card reader is stored in reader flash memory, which allows that software to be updated at any time—to get new versions of existing applications, to add new applications, even to update the existing OS and driver software. N*Able's field update protocol manages the updating of this software secure while also ensuring that the reader can continue to function in case of an interruption during the update process such as a power outage.
Field Update is described in detail in the Dynamic Application Download API white paper. This section provides a general summary of how field update works, including the structure of the reader's flash memory, how update data is structured and signed, and how the update process works.
Successful field updates depend on the structure of the flash memory within the reader. The secure reader flash memory is separated into four main parts:
Both the recovery and operational image sections contain a checksum of their contents. When the reader is booted, the boot section verifies the checksum of the operational image with its checksum, and then switches execution of the reader to the code in that image. If the checksum does not match, the recovery image is checked and booted instead (if the recovery checksum does not match, something has gone very wrong with the keyboard).
The data that will update the reader is a complete operational image: OS, drivers, apps, and so on, digitally signed by a central code signing authority (a CSA, typically the device manufacturer). This data, along with the CSA's signature, can be contained in a file, downloaded from the Web, or potentially stored on a server to which the N*Able secure reader can make a direct connection. The signature will be verified by the reader, which has a copy of the CSA's public key as part of its operational image.
From the user's point of view, the update process is simple: the user runs a Windows-based application called NableUpdate which displays the current reader software (stored in the operational image) and the software to be installed (the update data). If all looks correct, the user OKs the update process, and the update takes place, with NableUpdate informing the user of the progress of the update as it occurs.
Behind the scenes, the update process involves several steps:
Note that security of the update depends solely on the digital signatures and the cryptographic hashes calculated on the update data. All the signature verification, hash calculation and hash storage take place within the secure environment of the reader, where they cannot be tampered with. This means that neither the image data nor the connection between the host and the reader needs to be encrypted in order to ensure the security of the data—in fact, the data can be stored on the host after the signature is verified without fear of interim attacks.
Note also that checksum calculation of the new operational image takes place at the end of the update process. If the update is interrupted in the middle —for example, the reader was disconnected, or the power was interrupted, the reader's boot process will not find that checksum and will automatically boot from the recovery image. At this point the user can restart the update. This is a failsafe to prevent the reader becoming non-functional if the update is interrupted in the middle.
N*Able's development and support staff is eager to work with your organization in developing custom secure applications which meet your requirements for protecting you and your user's sensitive information. For a confidential discussion of your business needs, contact us at info@nabletech.com or visit our Web site at www.nabletech.com.
Specifications and features are subject to change. Contact N*Able Technologies for the latest specifications and features. N*Click and N*Able are trademarks of N*Able Technologies, Inc. Microsoft, Windows, Windows95, Windows98, Windows NT, Windows2000, and PC/SC are either trademarks or registered trademarks of Microsoft. Other product and company names mentioned herein may be the trademarks of their respective owners. RSA U.S. Patent N0. 4,405,829. Certain features of N*Able Security Architecture Patent Pending. Copyright © 1998-1999, N*Able Technologies, Inc. All rights reserved.