Requirements for Virtual Smartcard Services

A feature of PKI services is a need to store long-term personal security information (including private keys, certificates, and other information) in protected storage, to activate personal keys for use via an authentication procedure, and to use those keys for encryption, decryption, and signature activities.

There are two models for the processing and management of this information:

• One model (exemplified by PGP and Lotus Notes) manages private keys and personal data primarily on the client principal's machine (either in a software personal security module, or in a security token or other device external to the principal's workstation).

• The second model (exemplified by ONC RPC and Novell NetWare) manages private keys and personal data at a central server and distributes them to client principals using a secure protocol.

The first model may be supported by Smartcard technology in which the personal data is processed and managed within a separate hardware device (the Smartcard). However, the use of such Smartcards incurs the cost of additional hardware and software. They are therefore used in circumstances when the additional security they provide justifies the extra cost. An alternative approach is to use a software module in those circumstances when the additional security is not cost-justified.

From an application perspective it is not relevant whether a hardware or software module is used, provided the requisite data and services may be accessed. Hence the concept of a Virtual Smartcard service, which may be layered over either hardware or software implementations, may be envisaged within a system architecture. Virtual Smartcard Service Structure illustrates the structure of this component.

The concept of a software module may be further extended to encompass services provided under the second model, based on a centralized repository. In this model, the client/server protocol for retrieval of private keys needs to be supported by the software personal security module subcomponent of the Virtual Smartcard service component, as illustrated in Virtual Smartcard Service Protocol, (the dotted arrow in the figure represents the protocol):

The concept of a Virtual Smartcard service may be extended to encompass the processing and management of all personal security information, whichever model of implementation is used.

The Virtual Smartcard service will contribute to generic solutions for end users who are facing real situations that can be summarized as follows:

• Facilitate the handling of information related to multiple identities in a heterogeneous environment:

  • As members of an enterprise (corporate users), end users may have multiple identities depending on systems and applications they need to access. Whenever Single Sign-on is achieved in their enterprise IT, the multiplicity of identities continues to exist despite being hidden behind a single identity. An example of end-user identities is login names.

  • End users must be authenticated by heterogeneous applications in security infrastructures which combine legacy technologies (based on passwords, for instance) with public-key-based technologies.

  • As consumers of distributed services over the Internet (Internet users), end users do not use the same identity when they access, for example, a home banking service or an electronic commerce service. The Virtual Smartcard service is designed to support the handling of multiple identities by end users in the electronic commerce market place.

  • Permit users to store and access long-term personal security information certified by more than a single certification authority (handle multiple identities, and so on).

• To provide secure means of handling and managing personal data:

  • End users own data that can be qualified as personal information because it is data given to them, acquired by them, or generated by them. Certificates, passwords, private keys, or even identities are examples of this kind of data.

  • Permits users and other principals to store long-term personal security information (including private keys, certificates, and other information) in protected storage, to activate personal keys for use via an authentication procedure, and to use those keys for encryption, decryption, and signature activities.

• To support end-user mobility:

  End users are more and more mobile either within intranets or across them, or over the Internet. Therefore, they want to be able to transport their personal information securely.

• Avoid the need for and cost of uniform use of hardware devices:

  Support for the deployment of Smartcard techniques without the need to have Smartcard hardware implemented on every workstation.

• To be hardware-independent:

  • Support different hardware or software devices such as Smartcards, floppies, PCMCIA cards, or software modules

  • Support mobile devices such as Smartcards

  • Support multiple Smartcard technologies (which can be multi-application)

  • Support multi-PIN systems

  • Provide flexibility to accommodate the increasing functionality expected to be implemented within Smartcards as the technology evolves. The Virtual Smartcard service can facilitate this by enabling a varying mixture of software and hardware service implementations below the interface.

The following problem scenarios illustrate issues regarding the management of the information contained on Smartcards:

• Temporary access to services:

  What happens when someone leaves their Smartcard at home (enterprise environment)?

• Management of long-lived data:

  • Smartcards may have a limited lifetime for reasons of security, or just physical wear and tear

  • As functionality evolves, there is still a need to be able to preserve data

  • Hence there is a general requirement for export/import functionality which enables transfer of a key and other data from one Smartcard to another

Overview of Virtual Smartcard Services

A Virtual Smartcard service comprises three aspects:

1. A configuration capability that allows transparent handling of diverse hardware or software security devices. These devices will be used as personal data repositories or providers of security mechanisms.

2. An abstract data model through which personal information is accessed. This data model describes personal data in a two-level hierarchy. The first level consists of personal data domains (application domains or security domains); the second level consists of end users' identities.

3. A set of functions designed to:

   • Customize and initialize the data model

   • Configure the security devices where the personal data resides

   • Manipulate personal data through the data model

Example Data illustrates the type of data and a data structure that might be maintained by a Virtual Smartcard service.