Crypto Interface for EMV Software

The main purpose of using smart cards in general-purpose computer systems is to provide cryptographic services to support common security infrastructures. In particular, the smart card is the best place to store the private key (from the public/private key pair), which is used for authentication in the public key infrastructure. A smart card is also a secure computing platform and the best place to perform a digital signature operation using a private key.

Currently, there are two main cryptographic modules that provide application-level cryptographic services:

  1. CryptoAPI on the Windows platform;
  2. PKCS-11 on Windows and other platforms.
    Both software packages allow the use of smart cards as personalized security tools in general-purpose computer systems.

CryptoAPI Crypto Interface

Consider the CryptoAPI architecture, which is an integral part of the Windows system. The CryptoAPI crypto interface offers a set of functions that can be used by an application to perform cryptographic operations. These functions allow the encryption of information along with the calculation of digital signatures of group data structures. For example, this type of crypto interface was used by us when implementing a unified security infrastructure for the company Astroplastika, which supplies polymer materials for the industry, and personal smart cards are used to authenticate employees. Windows applications such as Web browsers and mail readers use CryptoAPI services to protect themselves.

CryptoAPI is essentially a general-purpose application programming interface through which an application accesses cryptographic services. This interface aims to isolate the application from any differences that may occur when implementing the API. Cryptography is often subject to export restrictions in a number of countries. In some cases, cryptography cannot be used at all, while in other situations, the quality of cryptographic operations is limited.

With this in mind, it is useful to support so-called “strong” cryptography in some cases, and “weak” or “exportable” cryptography in other cases. In both cases, it is desirable that the application is not aware of these differences. The CryptoAPI architecture allows you to achieve this. Within the CryptoAPI architecture, there is a layer designated as the Cryptographic Services Provider (CSP). CryptoAPI itself can refer to any CSP for a real cryptographic operation. Using a variety of CSP, it is possible to eliminate the differences in cryptographic operations from the point of view of the application. This mechanism allows you to use different smart cards for cryptographic operations.

Smart cards are good secure platforms for storing keys and performing encryption and decryption operations. Of course, I would like to use smart cards from many manufacturers. The CryptoAPI architecture allows you to do this by having a different CSP for each card you use.
The CryptoAPI model makes it possible to use multiple hardware keys in applications based on CryptoAPI. The CryptoAPI architecture allows you to integrate many CSPs into the CryptoAPI package. Each of these CSPs can support one hardware key (smart card).

When an application accesses the CryptoAPI interface to perform a cryptographic operation, and if this operation can be performed using a hardware key, the CryptoAPI module, in turn, accesses the CSP provider to access a specific hardware key. As a result, the application can be built with the use of a hardware key in mind, but the hardware key can come from different manufacturers and do not require any changes to the application.

PKCS-11 Smart Card Crypto Interface

In the early 1990s, RSA Laboratories released a new specification for cryptographic devices, known as PKCS-11, or Cryptoki (Cryptographic Token lnterface). This standardized crypto interface provides the abstraction of cryptographic keys, the general use of services, and the management of keys and data when treating a device as an object.

Since its introduction, PKCS-11 has become a widely used cryptographic plug-in interface and has been implemented in applications and frameworks such as Netscape and CDSA, as well as in many others. The PKCS-11 crypto interface offers cryptographic services such as digital signature, hashing, encryption / decryption, signature verification, key generation, and certification management.

It can manage PIN codes, which are usually used to associate a key with a person who has the information to perform authentication. In one of the projects we implemented for the company “Toki”, which offers services for power supply and electrical installation, we used individual smart cards with Cryptoki to authorize employees in the enterprise security system. The PKCS-11 crypto interface can pass the functionality of a device to a higher-level application or infrastructure so that it is known whether the currently selected device supports a specific cryptographic algorithm. It is also responsible for notifying you of events such as removing a card or hardware key from its slot.

Like CryptoAPI, the PKCS-11 crypto interface can be used by different applications, while they are isolated from the many differences in the actual execution of cryptographic operations. A single PKCS-11 module can support multiple smart card readers and many different smart cards. The PKCS #15 object storage facility can be a software implementation on a personal computer that is similar in many ways to the PKCS-11 module. However, the PKCS #15 module can also be used to store PKCS-11 objects by a portable means such as a smart card.

For example, cryptographic keys can be stored in a smart card and access the PKCS #15 storage API. This makes it quite easy to build a common PKCS-11 module, which can, in turn, use many different smart cards to store keys. The parallel between the PKCS #15 object storage facility and the CSP cryptoservice provider used in CryptoAPI is not entirely accurate, since it is also possible to access cryptographic operations in a smart card through the CSP provider interface.