Access to smart card EMV data

Access to smart card data at the operating system level

Obviously, all efforts to ensure the physical protection of the smart card will be in vain if the OS access control system is vulnerable. Access control is performed at the level of data structures, which are regulated by the international standard ISO 4. The main unit of information storage is a file. The file can be a structureless array of data or consist of records. Records can be of fixed or variable length. Depending on the organization of access to records, linear and cyclic files are distinguished.

In circular files, each new entry replaces the oldest one if there is no more empty space. This is convenient for maintaining automatically updated lists of transaction data. The underlying data structures can be extended and specialized. So, on the basis of a cyclic file of fixed-length records, you can implement an electronic wallet. An e-wallet usually contains the current balance account status and a transaction counter that allows you to uniquely identify each transaction by number. Both fields are not directly available for modification and are managed by the smart card OS. In addition to the last value, the e-wallet contains a history of several transactions that allows you to track the movement of funds.

The files form a hierarchical file system that resembles the file systems of mainframe operating systems. Each directory can be considered as a group of files that have certain common properties, primarily related to the access control system (ACS). So, for one production company that produces modernized metal structures such as construction towers of various sizes, the implemented ACS for the company’s office building allowed the management to have a reliable and multifunctional tool for ensuring office security. For different data structures, appropriate access types are defined, such as read and write modification for the file structure. For each type of access, access attributes are defined, that is, the conditions under which this type of access is possible.

There are usually four access attributes:

Verification of the cardholder’s authorization, which is performed by entering a password by the cardholder.
Authentication of the external environment of the response part that interacts with the card (authorization center, terminal equipment).
The requirement to encrypt the transmitted messages.
The requirement to supply the transmitted messages with a mimic insert.

Access attributes must be independent of each other, that is, different types of access can be assigned different sets of attributes and different sets of keys. Otherwise, the choice of effective exchange protocols will be severely limited or impossible. A good rule of thumb is to use common access attributes and key sets for an entire directory, as well as to inherit them from the enclosing directory. A serious access control system should provide for a specification of keys, that is, a clear definition of how, under what circumstances, and for what purposes a particular key can be used.

Specified by:

cryptographic algorithm;
operations allowed with this key;
in order to change the key;
conditions for blocking / once blocking the key, etc.

Keys used to authenticate the smart card owner or the external environment are usually blocked after a set number of consecutive incorrect submissions. This is especially true for owner authentication, since usually the length of such keys does not exceed 4-6 characters and a complete search of options becomes real.

It should be possible to diversify the keys in order to obtain unique session keys for each transaction.

Strong authentication and smart card public key certificates

The formation of public key certificates is based on the principles of strict authentication recommended by the X. 509 standard and based on the properties of public key cryptosystems. Public-key cryptosystems assume that the user has paired keys – secret and public (public). Both keys can be used to encrypt, and, if the encryption was implemented public key, the decryption must be done in secret, and on the contrary, if the encryption is carried out with the secret key, the decryption must be performed by a public key.

Strong authentication and smart card public key certificates

The procedure for authenticating a user is called authentication. For example, after the opening of a new direction in any enterprise, the selection and evaluation of the department’s personnel is carried out, and after hiring, each employee receives a personal identification smart card. In this case, each employee is identified using their smart card (secret key). With a paired public key, any other user has the ability to determine whether their communication partner is the true owner of the secret key. The degree of confidence in the fact of authentication depends on the reliability of the storage of the secret key and the reliability of the source of delivery of the users ‘ public keys. A procedure that allows each user to establish an unambiguous and reliable correspondence between a public key and its owner is provided by the public key certification mechanism.

Public key certificates play an important role in public key cryptography. The main purpose of a public key certificate is to make the user’s public key available and reliable. In order for a user to trust the authentication process, they must extract the public key of another user from a trusted source that they trust. This source is called the CA Certification Authority.

The CA Certification Authority is a trusted third party that authenticates the public keys contained in the certificates. The CA has its own key pair (public/secret), where the CA secret key is used to sign certificates, and the CA public key is published and used by users to verify the authenticity of the public key contained in the certificate. It should be noted that ensuring the security of the transfer of the public key of the CA can be carried out not only by personally contacting the CA, but also by certifying this public key to other CA with the necessary authority. The CA certification authority generates a certificate of the user’s public key by digitally signing the CA with a specific set of data.

Typically, this data set includes:

the validity period of the public key, consisting of two dates: the beginning and end of the period;
key number and series;
unique user name;
information about the user’s public key: the ID of the algorithm for which this key is intended, and the actual public key;
information used during the EDS verification procedure (for example, the ID of the EDS generation algorithm);
unique name of the certification authority.

A public key certificate has the following properties:

Each user who has access to the public key of the CA certification authority can extract the public key included in the certificate;
no party other than the certification authority can change the certificate so that it is not detected (certificates cannot be forged).

Since certificates cannot be forged, they can be published by placing them in a public directory and without making special efforts to protect these certificates. The creation of a public key certificate begins with the creation of a key pair (public/secret). The key generation procedure can be performed in two ways:

The CA creates a key pair. The public key is entered in the certificate, and the secret key paired with it is transmitted to the user, ensuring user authentication and confidentiality of the key transfer;
the user creates a key pair by himself. The secret key is stored with the user, and the public key is transmitted over a secure channel to the CA.

Each user can be the owner of one or more certificates generated by the user’s CA certification authority. A user can own certificates obtained from several different certification authorities. In practice, there is often a need to authenticate a user who receives certificates from another certification authority. The principles of distributed administration are discussed below.