Smart cards can enhance the security of many web applications -- they provide a secure and mobile platform for authentication and non-repudiation. In this article we look at the problems they solve (and do not solve), and the factors to be considered in their selection
Smart cards can enhance the security of many web applications -- they provide a secure and mobile platform for authentication and non-repudiation. In this article we look at the problems they solve (and do not solve), and the factors to be considered in their selection.
Smart cards perform cryptographic operations where the private key never leaves the card; all crypto operations involving the private key are done on the card itself and that improves security. They solve two key security problems:
- First, they introduce strong authentication based on client certificates– thus several risks related to passwords can be mitigated. For example, the risk of users accidentally revealing passwords is removed. Users are not required to remember complex passwords or worry about password expiry. Further, the possibility of passwords getting stolen from network traffic or browser memory is avoided. Only a user having the card can get access to application. And by using a PIN to authenticate the user to the card, the threat of someone using a stolen card is addressed.
- Second, they prevent modification and repudiation of transactions through digital signatures. The verification process on server can ensure that a transaction is not approved if changes are done to the transaction data. Smart cards make this easier for web application by providing a mobile way to carry client certificates and perform crypto operations.
Deploying Smart Card enabled applications
Let’s look at the factors to be considered for a successful deployment of Smart card enabled application:
- Selection of hardware: Each end user requires a smart card with associated card readers. These are widely available today from GemPlus, Schlumberger
and IBM. Important criteria while selecting a card are the cost of hardware, reusability of cards (whether the card can be reassigned if a previous user discontinues its use), life expectancy of card, chip memory size (32kb, 64kb etc. depending on the size of data to be stored), type of card reader (PCMCIA, USB or Serial). These will vary depending on your applications and environment.
- Selection of development platform: Programmers have a choice between Microsoft Smart Card SDK and Java OpenCard framework (OCF). The Microsoft
SDK provides device independent APIs for developing Smart card applications. A consortium of IBM, Sun Microsystems, Netscape and others developed
OCF (www.opencard.org) as a standard for accessing Smart cards in Java. The services of the smart card can be invoked from an ActiveX control or Java Applet embedded in the html page.
- Training: Plan for end-user training to familiarize users to the new technology. Users also need to be educated about the correct use and protection of Smart cards. For example, exposing cards to moisture or high temperatures can damage them.
- Policies and procedures: Design policies and procedures well before the distribution of cards to users. Set processes for support activities: issuing new cards, disabling and replacing lost, stolen and damaged cards.
Smart cards are of course not a silver bullet for application security; there are many risks that cannot be mitigated by Smart cards alone. For instance, cards do not validate data. Risks from un-validated inputs, insecure session management, pages being stolen from cache all require the application to be written securely even when Smart cards are used. The use of Smart Cards should hence be coupled with secure development practices to ensure that the application is safe.