SmartAdaptor™

1. SmartAdaptor™ PKCS#11 Interface for Smart Card/Reader applications

2. SmartAdaptor™What problems does it solve? • RSA's PKCS#11 is an industry-standard security provider commonly used by secure applications. However, significant shortcomings have become apparent: • An application cannot operate easily with multiple PKCS#11 providers. Use of multiple providers on the same program flow may cause serious complications. In contrast, suites like PC/SC, CAPI, CDSA were designed from the outset to support multiple providers.

3. SmartAdaptor™What problems does it solve? • PKCS#11 entered the concept of slot and token. However, since the concept of a provider is absent, there is no standard way to separate slot-dependent code from token-dependent code. As a result, it complicates the use of smart cards and in case of different vendors it does not support interoperability. • Reader interfaces inadvertently use mutually incompatible standards such as PC/SC, CT-API or proprietary methods. • PKCS#11 defines a lot of cryptographic mechanisms. While some of them are mandatory for operating a specific provider (e.g. for a signing token), others may be optional. However, PKCS#11 vendors still supply a lot of optional mechanisms to support more applications. The reuse of crypto-functionality for both applications and PKCS#11 vendors would be very appreciated.

4. SmartAdaptor™What is it? A software tool that: • Enables multiple PKCS#11 providers to coexist and from the application's perspective, causes them to be implemented as a single PKCS#11 package. • By use of plug-ins, SmartAdaptor enables various smart card providers to interoperate with the different readers that are recognized in the system, leaving the details (reader recognition, interface, etc.) to the SmartAdaptor.

5. SmartAdaptor™What is it? • Frees PKCS#11 providers from the need to implement crypto-mechanisms. By relying on the basic algorithms, providers can focus on their specific implementations, contributing to the efficient reuse of code. • Imposes thread-safety by serialization of requests even when a particular PKCS#11 provider does not support it. • Allows loading of only trusted providers.

6. SmartAdaptor™How does it work? • Relies on PKCS#11 standard • Views smart card and reader as distinct providers • Defines three basic types of PKCS#11 provider: • PKCS#11 Core Provider - self-contained PKCS#11 library, supported without any modifications. • PKCS#11 Card Provider - library, which externally has a PKCS#11 interface, and internally relies on proprietary smart card API; it uses callbacks supplied by SmartAdaptor to communicate with the readers. • PKCS#11 Reader Provider - library, which provides an interface to a proprietary reader, established according to SmartAdaptor rules. • Defines simple provider registration API

7. SmartAdaptor™How does it work? • Defines simple reader access API to enable PKCS#11 Card Providers to interoperate with all readers. • Recognizes PC/SC readers automatically, no adaptor needed. • Recognizes CT-API compliant readers, no adaptor needed (though registration is still required). • Provides software (virtual) token support with a full set of crypto-mechanisms implemented in software. • Provides default user interface functionality for obtaining the PIN when the token does not support a protected authentication path. This user interface can be customized by the application.

8. SmartAdaptor™Adaptation to existing APIs and applications • SmartAdaptor includes a set of additional layers: • CAPI adaptation layer– allows PKCS#11 vendors to become plug-ins to Microsoft applications (IE, Outlook). • Entrust adaptation layer– allows PKCS#11 vendors to become plug-ins to Entrust applications. Though Entrust is in principle PKCS#11 enabled, early versions are based on PKCS#11 v1.0, which is incompatible with the current PKCS#11 version. Even Entrust v5.x, which is PKCS#11 v2.x compliant, still requires some adaptation to operate with a standard PKCS#11 module. • Java adaptation layer – allows Java applications to access PKCS#11-based cryptographic devices.

9. SmartAdaptor™Architecture APP 1 APP 2 APP 3 . . . APP n 3rd Party Entrust Adaptor CAPI Adaptor Java Adaptor PKCS#11 API • Provider Registration API: • Core Provider • Reader Provider • Card Provider User Interface API SmartAdaptor SmartAdaptor Software Token Crypto Algorithms Simple Reader Access API PKCS#11 Reader Provider PKCS#11 Core Provider PKCS#11 Card Provider 3rd Party PC/SC Reader CT- API Reader Proprietary Reader

10. SmartAdaptor™Registration API • With SmartAdaptor, in order to register a provider, an application needs to create a registration context: CreatePKCS11ProviderContext CreatePKCS11SmartcardProviderContext CreateSmartcardReaderContext to supply information about provider name, path, ATR of card with comparison mask (in the case of smart card provider), possibly some other information and register provider: RegisterProvider Context must be released at the end of registration: FreeContext

11. SmartAdaptor™Registration API • Several services for obtaining information about registered providers, modifying data, and searching are supplied : GetProviderData SetProviderData AddATRToList ListProviders All provider-related information is stored in fields. SmartAdaptor has a set of predefined fields, though vendor-defined fields are also supported. Fields are presented in TLV form.

12. SmartAdaptor™Reader Provider • Proprietary reader vendors must provide an interface according to a simple generic access API defined in SmartAdaptor : • power on ( parameters : input - slot ID , output - ATR ) • power off ( parameters : input – slot ID ) • transmit ( parameters : input – slot ID and send Buffer, output – received Buffer ) • get card status ( parameters : input – slot ID, output – card state(inserted, powered, etc. )) • A reader vendor must also supply an Entry function, which provides pointers to the above interface functions. • The name of the Entry function must be supplied to SmartAdaptor during reader provider registration.

13. SmartAdaptor™Smart Card Provider • Smart card providers working under SmartAdaptor can interoperate with any PC/SC, CT-API or proprietary reader. All they need is to use callback functions provided by SmartAdaptor, instead of direct calls to the reader interface. • During registration the smart card provider should supply the name of an Entry function, which can be used by SmartAdaptor to provide it with the callbacks. • During C_OpenSession, SmartAdaptor retrieves the ATR of the card inserted in the slot and looks for a registered provider with matching ATR. (Mechanisms for multi-application card recognition will be added in the next version of SmartAdaptor).

14. SmartAdaptor™Smart Card Provider • When a smart card provider is found, SmartAdaptor loads the appropriate library and calls the Entry function, where the smart card provider can find the callback functions to communicate with the reader. • The smart card provider must work with the readers via the callbacks supplied by the Entry call, using the slot IDs obtained from C_OpenSession call. • Smart card providers can always recognize the reader they currently work with, and for readers with known special features, SmartAdaptor enables smart card providers to gain direct access to the reader. • SmartAdaptor takes responsibility for synchronization of requests to the reader made by threads and applications.

15. SmartAdaptor™Solution • The solution is already proven and fully operational. • Supported platforms: Windows 95/98, WinNT v4.0, Win2000 Next version: Unix