EA001837B1 - Chip card and method for its use - Google Patents

Abstract

1. Chip card for performing transactions in which monetary units or other value data representing non-monetary entitlements are transferred between the cardholder and at least one transaction partner (service provider) or are presented to the service provider for verification of entitlements, wherein the chip card includes a storage, in which data required for performing the transactions are stored and the chip card is characterised in that it comprises the following: a means for loading one or more card applications (VAS-applications) which are assigned to a certain service provider, respectively, onto the card which each permits the performance of transactions between the cardholder the service provider assigned to the application; a transfer memory portion (EF_TRANSFER) which is not proprietory to a service provider for accomodating data which in the performance of a transaction between different service providers are to be interchanged or presented and which represent the monetary units or non-monetary entitlements; and a means for writing data into the transfer storage by reaction to a write command (Transfer). 2. Chip card according to claim 1, in which the means for loading comprise: a data structure (DF_VAS, VAS-container) stored therein which includes; a partial structure (DF_PT, DF_AD, VAS-application) into which the data required (VAS-data) for making possible the performance of a transaction between the cardholder and a service provider can be loaded; a definition data set which contains information concerning the nature and/or structure of the data stored in the partial structure (VAS-application); and wherein the definition data set further comprises: a denotation (container-ID) which identifies the data structure (VAS-container) and/or the chip card; and at least one system key (KSO) which secures the integrity of the definition data set and/or the data structure (VAS-container) against modifications. 3. Chip card according to claim 1 or 2, characterised in that it comprises at least one of the following features: a means for loading data necessary for the performance of transactions into the partial structure with the aid of at least one system key; a means for the writing of data into the definition data set for adapting the data of the definition data set to the data loaded into the partial structure; a means for generating a further partial structure into which data required for performing a transaction can be loaded in the database of the card; and/or a means for dynamic memory administration on the card. 4. Chip card according to any one of the preceding claims, characterised in that the partial structures (VAS-applications) are represented by mutually independent partial structures each being assigned to a particular service provider, the definition data set is protected against modification by the at least one system key (KSO) and can only be modified by means of this key, and that loading of the partial structures (VAS-applications) can proceed only with the use of the system key contained in the definition data set. 5. Chip card according to any one of the preceding claims, characterised in that the definition data set comprises at least one of the following features: at least one authentication key (KAUT) for authenticating the entitlement of the chip card in relation to a terminal and/or for authentication of the entitlement of a terminal in relation to the chip card; at least one signature key (KSIG-VASC) for signing data removed from the transfer storage; a key generating key (KGKDEC) for generating terminal and application specific keys for the verification of the authorisation for a writing procedure into the transfer storage and/or a invalidation of value data; a PIN for the verification of the authorisation of a transaction procedure by the cardholder, that the system key (KSO), the authentication key (KAUT), the signature key (KSIG-VASC) and the key generating key (KGKDEC) are keys individual to the cards or specific to the data structure (DF_VAS), and that the partial structure (VAS-application) comprises at least one of the following features: at least one value storage (EF_VALUE) for the storage of value data; at least one internal storage (EF_INTERNAL) for the storage of internal data relating to the partial structure; at least one information storage (EF_INFO) for the accommodation of non-internal data relating to the partial structure; a key storage (EF_KEY) for accommodating at least one key (KLVASP, KRVASP), which provides security for the writing and/or information retrieval procedure into or from the value storage and/or the internal storage and/or the information storage and that the chip card further includes:a means for writing and/or retrieving data into or from the value storage, the internal storage or the information storage and that the means for loading includes: a means for writing the key into the key storage, protected by the at least one system key. 6. Chip card according to any one of the preceding claims, characterised in that the partial structure comprises at least one of the following integers: a key (KLVASP) for checking the authorisation to write data in the partial structure: a key (KRVASP) for checking the authorisation to retrieve data from the partial structure. 7. Chip card according to any one of the preceding claims, characterised in that keys stored in the key storage are specific for the respective partial structure and that the at least one partial structure (VAS-application) protects the performance of transactions by means of at least one of the specific keys (KLVASP, KVASP) which is specific to the respective partial structure (VAS-application) and is independent of the keys for other partial structures (VAS-applications). 8. Chip card according to any one of the preceding claims, characterised in that the card comprises a plurality of partial structures (VAS-applications) which each serve for the performance of transactions between a particular service provider and the cardholder and that the performance of transactions includes the writing and/or retrieval of data into, respectively from the transfer field and/or the writing and/or retrieval of data into, respectively out of the value storage. 9. Chip card according to any one of the preceding claims, characterised in that it further includes: a means for performing transactions both between individual partial structures (VAS-applications) as well as between a partial structure and a service provider. 10. Chip card according to any one of the preceding claims, characterised in that the system key (KSO) is known only to the system operator (SO) and is a key individual to a card and/or specific to a data structure (VAS-container), and that the further keys contained in the definition data set are keys individual to the card and/or specific to the data structure (VAS-container). 11. Chip card according to any one of the preceding claims, characterised in that the definition data set includes one or more of the following integers: an identification number (EF_ID) specifying the data structure a directory of partial structures (EF_DIR) contained in the data structure, the directory containing partial structure specific identification numbers of partial structures (VAS-applications) loaded into the data structure (VAS-container), as well as information containing that part of the data structure (VAS-container) in which the partial structures (VAS-applications) are physically stored; a version number of the data structure (EF_VERSION). 12. Chip chard according to any one of the preceding claims, characterised in that it includes at least one of the following features: a means for performing a withdrawal procedure (Take) by means of which data can be removed and/or value-cancelled from the transfer storage; a means for generating one or more authenticity features of the data during withdrawal or cancellation of data from the transfer storage. 13. Chip card according to any one of the preceding claims, characterised in that the chip card for generating the authenticity features comprises the following: a signature key (KSIG-VASC) for generating a digital signature having the data withdrawn; a means for generating a transaction number characterising the transaction which is also used in the generation of the digital signature. 14. Chip card according to any one of the preceding claims, characterised in that the signature key (KSIG-VASC) is a private key, derived from a private key generating key and that for checking the signature by the service provider, public keys are employed. 15. Chip card according to any one of the preceding claims, characterised in that it at least comprises one of the following integers: a means for generating terminal and partial structure-specific keys (KDEC) by means of the key generating key (KGK DEC); a means for verifying the authorisation and/or the protection of a transaction by using at least one of the following integers: the terminal and partial structure-specific key (KDEC), the at least one authentication key (KAUT), the at least one system key (KSO), the at least one partial structure specific key (KLVASP, KRVASP), the signature key (KSIG-VASC), the PIN, the identification of a partial structure, the identification of a terminal. 16. Chip card according to any one of the preceding claims, characterised in that the chip card includes at least one of the following integers: a means for authentication of the authority and/or the terminal by means of the authentication key prior to starting a data retrieval or writing procedure, a means for performing data retrieval or writing procedures which are protected by a digital signature and/or key formation. 17. Chip card according to any one of the preceding claims, characterised in that the chip card further includes at least one of the following integers: a means for activating and deactivating the PIN-prote

Description

The present invention relates to a chip card (i.e., a card with an integrated chip), a terminal used with a chip card, a method for using a chip card, and a chip card system.

Microprocessor chip cards with a payment function, for example, with the function of electronic money, non-cash payment and cash receipt using the Eurocheck system, a credit card function, etc. are already used. and, depending on their issue, by organizations such as the Central Credit Department ΖΚΑ (2sp1ga1sg Kge6yaii88si88), U18A or EMU (Eigorau Mayetsatb U18A), the norms are established by which they can be used as a means of payment (money surrogate). The following publications should be mentioned as examples of their description in this connection:

- ΖΚΑ, Ζеηйа1е ^ Kgebyashksyshk, 8s11sh1181e11ep8re71ykayop 1ig b1e es-Kaye ty Syr, 10/27/1995;

- Eigorau 1p1etpa1yupa, 1p1edta1eb Sysy Sagb, 8reisa1yup Got Rautep! Zuyetk, EMU '96 U 3.0, 06/30/2006;

- 18O / 1ES 7816-4, Shotta Iop 1 espoduode Iepysayop satbk - 1p1edta1eb spsiy (8) satbk \\ ύ1ι sop! Asy, Paradise 4: 1p1eppbiytu sotstbk Gog sh! Eksyapde 01-09-1995;

- РТЕЫ 1546-1, Iepysayop sagb kuyetk 1p1et-8es1ot e1ec1toshs rigai, Paradise 1: OePnShop ^ companion apb itisIgek, 03/15/1995;

- РТЕЫ 1546-2, Hypysayop sagb kuyetk 1p1et-8es1ot eksyoshs rigai, Paradise 2: 8sityuu agsiyesNte, 07/03/1995;

- РТЕЫ 1546-3, Iepysayop sagb kuyetk 1p1et-8es1ot e1esyoshs rigai, Paradise 3: Ea1a e1etepy apb t1egsyapde8, 12/9/1994.

Up-to-date overview information on chip cards can be found in the publication 81eGai 8siy, Veg! Koidtag, Syrkayep, Tezipysye Megktae, Mogtypd, E ^ u8aΐzdeb ^ ee, publ. V. Oyepoigd Ug1ad, M (^ ps11ep / \ V ^ ep. 1996, Ι8ΒΝ 3486-23738-1.

Conventional chip cards can usually be used only for one specific purpose, for example, as electronic money or electronic identification card. This is due to the fact that the application programs (applications) installed in these chip cards are usually static, that is, they are inserted into the chip card during its manufacture and remain unchanged throughout the life of the chip card.

Thus, conventional chip cards are limited both in terms of their variability and in terms of their functionality, in particular, the functionality of conventional chip cards, once defined during the manufacturing process, cannot subsequently be changed.

Based on the foregoing, the present invention was based on the task of developing a chip card with variable functionality.

The next objective of the invention is to create a chip card, which allows after the manufacturing process to vary the number and type of applications implemented using this chip card, respectively, application programs and transactions. It should be possible to download additional applications to this chip card, the ability to delete applications from the chip card, and individual applications should be described in such a way as to provide independent processing and data protection and work independently of each other.

For example, the chip card must comply with the requirements of ISO 7816 for processing and data protection, however, the individual chip card applications themselves should be independent, in particular, from the chip card platform.

Another objective of the invention is the creation of a chip card that allows the user to determine, respectively select and change the number and type of applications used in his chip card.

In addition, the objective of the present invention is to create a chip card that enables and is able to implement both internal services (i.e., having closed applications in the sense that no transfer of payments and settlements with external partners can be made), and services communications (i.e., having applications that provide additional communications with external partners).

Thus, one of the objects of the invention is a device that allows you to upload one or more relevant applications to the chip card, which in each case enables transactions between the owner of the chip card and one or more service providers (providers).

Downloading provides the chip card with a configuration in which it acquires new functionality, i.e. she starts to run an application that previously could not work for her. The downloaded data describes, and in combination with the basic functions of a chip card, for example, the operating system functions implement applications that were previously absent in the chip card. Thus, the functionality of the chip card as a result of downloading the application is increased by this application.

According to one exemplary embodiment of the invention, the chip card of the invention has a data structure (OE_UA8), which in turn is subdivided into a sub-structure and a data description record, the data structure being uniquely determined using an identifying code and does not depend on it from the chip card platform. This solution allows you to load the so-called applications into the substructure, i.e. chip card functions or applications. Thus, it becomes possible, by loading a specific application on the chip card, to make transactions between the owner of the chip card and the provider specified for the application. The data description record inside the data structure contains information about the type and / or structure of the applications loaded into the substructure. At least the data description record, and preferably the entire data structure, is protected from modifications by at least one system key and can only be changed using this key. Instead of a system key, other protective mechanisms or protective devices can be used to protect data from modifications, such as a personal identification number (the so-called PIN code) or other devices that provide protection.

The above structure allows you to load into the substructure and also remove from the substructure various applications, changing the chip card in relation to its functionality, respectively, implemented with the help of applications. Download and delete applications by writing the specific data and codes of these applications in an existing substructure. The presence of a system key and a code identifying the data structure makes this data structure with multifunctional capabilities independent of the chip card platform as such, as well as self-sufficient and independent of this platform with respect to its data protection architecture.

In this embodiment, the chip card makes it possible, depending on the applications loaded into the substructure, to carry out transactions between its owner and providers, which depend on the downloaded applications.

In addition, the chip card preferably has a memory area for the data to be transferred, where, during data exchange, it is written, respectively, from where the data is read during transactions. Owing to the use of specific terminal keys for transferring data from the data region that transfers this data, individual access operations are not dependent on each other from the point of view of data protection.

Separate substructures available in the chip card, respectively, applications are preferably independent of each other and allocated in each case to a specific provider. For a particular provider, they, so to speak, are their own or specific data that allows them to use a specific application. Therefore, depending on the type of application and the specific provider, they contain various information, for example, data expressing a certain cost (reward points (bonus), account balance, etc.), information about the application, information about the provider, etc. d. Preferably, however, they also contain, in particular, the specific keys of this application, enabling access to the data of the substructure independent of other substructures from the point of view of data protection. In contrast, downloading or creating the substructure itself, respectively, applications are protected by at least one higher-level system key.

Prior to the transaction between the chip card and the terminal, preferably mutual recognition occurs using the application-specific authentication key or substructure provided for this purpose.

Then, for transactions, the data is written to the substructure reserved for the remote control application (additional service application), or read from it, or they pass through the memory area for the data being transferred. In the first case, specific application keys are used. In the latter case, a specific application key is used, and preferably also a specific terminal key, generated, for example, using the key generation key available on the chip card based on the specific application data. The data recorded in this way in the memory area for the transmitted data, the provider can then read through the terminal, which preferably occurs by marking the data stored in this memory area as canceled. If we are talking about a provider that is not specified for the recording application, the result of such an operation is the implementation of the so-called communication service, i.e. the exchange of data expressing the monetary value between different providers in favor, respectively, at the expense of the owner of the chip card. In addition, as an additional protection, the use of a PIN code or password is provided, a comparison with which confirms the right to conduct a transaction.

The presence on the chip card of a variable structure allows you to place a different number of different applications in it at different points in time.

The reliability of the data read from the memory for the transmitted data is preferably provided using a marking key, respectively using a digital signature or at least one key. In this case, the most preferred option is that the read data continues to remain in the data-transferring memory area and is only marked by the chip card as read. This option allows you to receive information about the transaction and after it. In this way and when protecting the sample, one-time data sampling can be logged.

In addition, it is most preferable to mark the data recorded in memory for the transmitted data with the end date of their storage period, after which they lose their value. This option makes it possible to implement applications that allow, for example, to provide a ticket with a certain validity period.

The preferred presence of the transaction counter allows you to uniquely identify and identify transactional data, respectively, digital data in relation to their belonging to the respective transactions.

The chip card of the invention in a preferred embodiment includes a hierarchical concept of memory, which is protected from changes at different levels by different keys and which can vary at the application level with respect to applications loaded in memory, each individual application being protected by its own specific keys from others applications and does not depend on them, and the entire structure is protected by at least one system key and the code identifying the structure and does not depend on the boards itself ormy chip card. The concept of memory for the data being transferred allows the exchange of data both between the owner of the chip card and the provider, and between the various providers themselves. The selection from the memory, respectively, the record in the memory for the transmitted data is also protected by keys, the latter being also specified for chip cards and applications, and also for terminals. The authentication performed before each transaction, as well as the optional presence of a PIN code or password, further increase the reliability of protection of the chip card proposed in the invention.

In paragraphs 21-30 of the claims, a terminal is intended for use with the chip card of the invention. The specified terminal is used to download and delete applications, conduct transactions, view data, as well as to perform other functions in combination with the corresponding applications and transactions. The method of conducting transactions between the owner of the chip card and the provider is presented in paragraphs. 31-33 of the claims, the definition of loading data into the proposed chip card is indicated in paragraphs 34 and 35, and paragraph 36 contains a definition of the entire system consisting of a chip card and terminal.

Below the invention is explained in more detail on the example of preferred options for its implementation with reference to the accompanying drawings, which show:

in FIG. 1 is a schematic illustration of a chip card according to the invention;

in FIG. 2 is a schematic illustration of the entire system of components of the invention;

in FIG. 3 is a diagram of a data stream throughout the system;

in FIG. 4 is a schematic representation of possible classes of applications and operations in the form of a transaction model;

in FIG. 5 is a schematic illustration of the security architecture of the chip card of the invention;

in FIG. 6 - file structure of a common class implementation of a remote container;

in FIG. 7 shows various implementation classes of a D-container using an example of one embodiment of the present invention;

in FIG. 8 is a diagram of a file structure of a remote container using one example of an embodiment of the present invention;

in FIG. 9 is a schematic representation of the file structure of the implementation class ΌΡ_ΡΤ and in FIG. 10 is a schematic representation of the file structure of the implementation class ΌΡ_ΛΌ.

Before proceeding to a more detailed description of the invention, it is necessary to define the terms used below.

ДУ: additional services (Eng. UL8 (Уа1ие Лббсб 8егу1се8)).

DU-chip-card: a chip-card of additional services is a chip-card that allows you to participate in the use of additional services. Along with other applications such as, for example, payment applications (i.e., electronic money function), the remote control chip card has a remote control container.

Remote control container: the additional services container contains file structures, access conditions, keys and (auxiliary) commands for managing remote applications and providing the functionality of remote applications.

Remote control applications: supplementary service applications contain remote control data (additional service data). Access to the remote control data is controlled by the remote control application. The remote control provider (provider of additional services) works in the remote control with one or more remote control applications. Using the remote control application enters, reads and processes the remote control data. The remote control application can be designed either to perform internal services, or to perform communication services with external partners.

Remote control provider: an additional service provider responsible for its remote control application, which it develops in accordance with the general (framework) conditions of the system operator and its own requirements, and then provides chip cards to the owners through the system operator and terminals. Before they can be used, the remote control applications must be loaded into the remote control of the remote control chip cards.

Internal services (1i (gakeguu1se): a certain type of remote control application used under the exclusive guidance of the respective provider. Internal service applications are closed applications in the sense that there are no payment transfers or settlements with external partners. The remote application may be designed either to perform internal services , or to perform communication services with external partners.

Communication service applications (1i (egkegu1sec): these are internal service applications that support additional communications with external partners through a remote control container. A remote control application can be designed either to perform internal services or to perform communication services with external partners.

System Operator (SO): The system operator, or system owner, provides the remote control system to providers and chip card holders for use.

Issuer: a person issuing and issuing a remote control chip card with a remote control container.

Chip card holder (DK): holder or user of a chip card (in this case, a remote control chip card) and using this chip card to participate in the use of additional services. This person does not have to be the direct owner of this chip card.

Service terminal: the service terminal is set by the system operator for remote applications. At the service terminal, the owner of the remote control chip-card can control the remote control applications available in it (download, view, delete, and transfer remote control applications).

Trading terminal: has the functions of payments and, in addition, has the functions of additional services. In it, the owner of the chip card inserts his remote control chip card in order to, on the one hand, make a payment, and, on the other hand, to take advantage of the additional services.

Application Identifier (ID): the name of applications having a length of no more than 16 bytes for their unique distinction and the possibility of selecting applications from the outside, without knowing the file structure of the chip card. The IDP consists of a registered application provider identifier (English Rreshchegeb ArrIsayoi RgoU1beg GO (KTO)), 5 bytes long and optionally from the registration of their own application identifiers (English Rgorpe1agu Arrykayoi IeptsPeg Ked1k1ga1yui (ΡΙΧ)) with a length of not more than 11 bytes.

ΌΡ (from the English EyesYugu RPe): help file according to the standard Ι8Ο 7816. EP (from the English E1eteShagu Rie): elementary file according to the standard Ι8Ο 7816. Valid remote control container: remote control that can authenticate itself with respect to the outside world.

Key Identifier (IR): The key number in the key containing elementary file.

K & K (from the English. Ki1ek aib K.edi1a1yuik): regulatory framework. p: maximum number of objects of the implementation class BR_RT. a: maximum number of objects of the implementation class ΌΡ_ΑΌ. ητ _ϋΙΚ : total maximum number of objects: ητ _ϋΙΚ : = p + a. The number of entries in the elementary file ΕΡ_ΌΙΡ. is equal to ητ _ϋΙΚ .

pg _er _ _TKA No. _RE v.: the number of entries in the elementary file ΕΡ_ΡΕΚ8ΡΕΚ ..

In FIG. 1 schematically shows the structure of a chip card according to the invention. In addition to the static and unchanged data entered during the manufacturing process, such as the main file (MP from the English Mak1eg RPe) and the (optionally present) electronic money function (reference file ER_Vbg5e (from it. Vbgke - wallet), the catalog also contains a catalog , respectively, data structure or file structure (help file ER_UA8). The latter serves to host additional services (DU). The presence of these additional services, which are applications that can be downloaded to the chip card and later The deadline, i.e. after its manufacture, gives such a chip card flexibility, allowing it to vary its functions and the transactions made using it. The so-called remote control container provided in the proposed chip card (help file ER_UA8) provides flexible options for varying the chip functions -cards and, in addition, it separates the applications located in the chip card in terms of data protection from its platform, making the latter independent of the chip card platform and allowing even if necessary to transfer them to another chip card.

The implementation of the proposed in the invention of new additional functions (remote control) is based on microprocessor chip cards using the remote control container. The remote control contained in the microprocessor chip card creates a platform for hosting remote control applications. Remote control applications are appropriate options for implementing certain additional functions.

In the case of the electronic money function, separate mechanisms are provided for payment using a chip card (payment function) and for using the remote control application (additional function), although from the point of view of the user or the owner of the chip card, this may look like one process.

The microprocessor card is expanded by adding a remote control container capable of accepting various and independent applications. It provides the input, removal and transfer functions of these applications, which can only be used by an authorized system operator. In terms of data processing and protection, the remote control container is independent of other system components of the microprocessor integrated circuit. The DU container fully contains its own description and can work independently. An independent data protection architecture is defined for it, so remote applications use independent protection functions. The security architecture uses specific chip card keys that are not specific to a particular manufacturer and are not dependent on the identification characteristics of the chip card platform.

The remote control container also uses mechanisms for obtaining derivatives of specific terminal keys. With their help, the DUcontainer itself can actively check the reliability of the terminals, respectively, the reliability of the data they generate.

In the remote control container are placed remote control applications, which, using the mechanisms of the remote control container, provide data, thus ensuring the management of the corresponding interfaces. The DU-container provides the possibility of reliable exchange, as well as the management of data exchange within the framework of communication services between partners. The DU-container carries out active control, checking the reliability and singleness of the transmission of the values contained in the data.

The advantage of the remote control container over other approaches to creating chip cards containing many applications is that this concept is independent of any particular chip card platform. It provides a security architecture that is independent of the specific security mechanisms of the platform (such as keys, credentials, PINs, use of signatures / digital signatures).

Another advantage of the DUcontainer concept is that the number of different applications of the chip card is not fixed, due to restrictions and settings that were in force at the time of manufacture or release of the chip card. The user of the chip card can freely select the set of applications he needs at the moment, which limits only the capacity of the corresponding chip memory card. The number of remote control applications currently loaded on the chip card depends on the actual use of the chip card. The user of the chip card individually compiles a set of remote control applications of his chip card. The above applies to the possibility of subsequent changes to this set. The DU-container allows you to get a multifunctional chip card, the functions of which during its life can be selected and used, varying them in the number and type of applications. Such a solution also makes it possible, using only one chip card, to place applications in it, which until now required separate special chip cards. You can also transfer remote applications to other chip cards. This allows remote applications to serve longer than the life of one chip card and accompany the user of the chip card throughout the life of the applications.

The microprocessor chip card that provides additional services is a storage medium suitable for distribution and sale of services requiring access to protected data. Such a microprocessor chip card can be used as a means of payment, an arithmetic device and to store information about the cost. The client has the flexibility to independently supply it in accordance with his wishes with the functions of additional services and use it to manage these functions. The chip card also actively controls the authenticity and right of access to the information of the terminals involved in the work and ensures the one-time use and reliability of the transmitted data.

In FIG. 2 shows a general view of a system with system components represented therein.

The system owner (system operator) provides the system for use. On service terminals (CTs), you can download, delete, and transfer remote control applications. Other operations are selection, viewing, interpretation, etc. Remote control applications.

Suppliers of remote control applications, the so-called remote control providers, develop their own remote control applications in accordance with the general conditions of the system operator and, as far as possible, in accordance with their own requirements. The presence of a digital signature at the end allows you to verify the authenticity of the corresponding terminal programs.

In FIG. 3 shows the data flow in the system.

The system operator issues remote control applications to the terminals for use by chip card users. Before sharing the remote control application, you must load the chip card of the invention in the remote control container.

Trading terminals (TT) allow you to use the applications available in the DU11 chip card by entering, or deleting, the DU data accordingly.

To receive a microprocessor chip card with additional services (DU) functions, in this chip card along with other existing applications (for example, payment applications such as electronic money), the DU container is loaded.

The remote control uses functions that allow you to load, delete and transfer remote control applications. The specified control functions are used only by the system operator, and on the chip card they are protected from unauthorized use. The remote container has a memory for the data being transferred, which provides data exchange between remote applications.

To manage the memory for the transmitted data, two commands are used: ΤΚΑΝ8BEK. (TRANSMISSION) and ΤΑΚΕ (SELECTION). Team ΤΚΑΝ8ΡΕΚ. generates an input message in the memory for the transmitted data containing the specific data of the corresponding application. Along with useful information, this also includes information necessary for processing data, such as the date, expiration date, and identification data. The ΤΑΚΕ command provides the selection of objects from memory for the transmitted data and marking them as read. Depending on the particular application, the objects are then marked as continuing to be valid or as invalid. The DU-container checks the validity of the transmitted data and the singleness of its transmission.

Remote control applications use remote control data to provide applications and manage them. Access to the remote control data is controlled by the remote control application using the mechanisms provided in the remote control container for all applications. The remote control provider works in the remote control with one or more remote control applications. The use of remote control applications involves the input, reading and processing of remote control data.

The remote container supports communication services. Communication services require access to public information, transfer of rights to receive payments and settlement of payments and services between various partners.

Below, the possible services, respectively, of the application of the chip card proposed in the invention are explained with examples of its implementation.

The description in each case relates to the method of release and function of the chip cards in accordance with the prior art. These functions will be reproduced in the future using one or more remote applications.

First, internal services are presented.

Example A: Customer Club.

The department store organizes a club of customers. The client becomes a member of this club and receives, along with the status of a member of the club, certain services that persons who are not members of the club cannot receive. Today the membership of a club to his club is determined by the presence of his club membership card. A membership card is issued upon entry into the club, is not transferable to other persons and, as a rule, has a certain validity period. With the help of a membership card, no specific trading operations are performed, i.e. there is no connection with the volume of sales of department store goods to the buyer. This distinguishes the club membership card from reward programs in which there is a relationship between the status of a member and the volume of sales.

Similar examples: wholesaler / distributor certificate, 8epaog Sagb card, membership in a book club.

Purpose: membership in the club must be confirmed by the application in the remote control container.

Example B. The system of bonuses / rewards.

The buyer or client receives for each transaction (transaction, transaction or purchase) the right to a certain final reward. As a result of accumulation, the amount of remuneration that a given buyer or client can apply for is growing, and the buyer or client can at a certain time set by him exchange this right for a material service. The right to receive remuneration is valid for a certain period of time and may be granted to certain persons or act without specifying a person. The right to remuneration is determined on the basis of turnover or sales volume or based on the frequency of use of the buyer or client with the relevant services.

A similar example: the number of points used in the Myek & Mogue discount system provided by airlines and car rental companies.

Purpose: The score in the remote control container must manage the score.

Example B. Discount.

The buyer or client receives a planned discount on sales / turnover. A discount is provided for each individual transaction / operation. The chip card does not manage information on the previous turnover. Each transaction represents a completed operation.

Purpose: The remote control application should show the right to receive a discount.

Example D. Identity card function.

The relevant person, on the basis of the distinguishing features of his chip card, can confirm with third parties his right to receive certain payments or services. The identity card belonging to a specific person must be confirmed with each transaction (photo, PIN, biometric data). The identity of the identity card is used as a security feature.

Similar examples: Internet access, access to the electronic communication system for communication with banks and other financial and credit institutions at home (Note Vaikshd), phone card.

Purpose: The remote control application must confirm the right to receive certain payments or services.

Example D. Unit of value.

Value units receive and spend as a result of single or multiple use of the chip card. For one transaction, the cost is reduced by one or more units. The right of use may be transferred and may contain restrictions on use.

Similar examples: a single ticket, a ticket for several trips, a concert pass, a ticket for 10 sessions of squash, a movie ticket, units of billable time for a telephone conversation.

Purpose: rationalization of calculations by using the remote control application.

Example E. Payments for the use of services.

The use of services is taken into account in time, frequency and quantity, and the calculation is made at the rates. It is not known in advance how much this service will be requested.

Similar examples: food ticket, short-term parking ticket.

Purpose: The remote control application should provide the ability to make payments at tariffs. The timely information necessary for the calculations in each case should be stored in the DUcontainer.

Example G. Memo (mobile data memory).

This application makes it possible to transfer chip card holder data to a provider, allowing you to automate processes that are currently still manual. The indicated data do not allow to obtain from them any information on the monetary equivalent of the data.

Similar examples: filling out lottery tickets, payment receipts for purchased goods, cashier's checks, telephone directory.

Purpose: The remote control provider should be able to read data from the chip card and in this way directly provide the appropriate service (for example, establish a telephone connection, select a list of necessary goods, fill out and register a lottery ticket by electronic means). Storage of data in the chip card can be both short-term and long-term.

Following the examples of internal services, several examples of communication services should be given.

A communication service always takes place if several remote control providers participate in it. This circumstance is inextricably linked with the fact that the information leaves the scope of one remote control provider. Today, this process is provided by paper supporting documents.

Example A. Reimbursement of fare.

The department store reimburses the buyer for the fare to the department store with local or suburban passenger transport. The buyer must present a single ticket in the department store. The department store notes the payment of compensation on the ticket. In certain cases, the department store, for its part, may receive part of the compensation paid by the buyer back from the transport company.

Purpose: The cost recovery process should be carried out electronically.

Example B. Discount coupon.

The department store reimburses the buyer for the purchase of goods the cost of a return trip to the house, giving him a coupon for a reduced fare. The buyer receives one ticket for it on the ticket office using public local or suburban passenger transport, respectively, pays a lower cost for the ticket. The transport company calculates this ticket with a department store.

Purpose: to display these mechanisms with remote control applications by electronic payments between trading enterprises and enterprises of public local or suburban passenger transport.

Example B. Parking for customers.

The department store partially reimburses customers for the cost of parking when they use a certain indoor parking lot. The owner of the covered parking lot is an independent company that receives a cash reward from the department store for each buyer who is connected.

Purpose: to display these mechanisms with remote control applications by electronic payments between the trading company and the indoor parking lot.

Example D. Multilateral remuneration program.

A group of commercial enterprises and service providers agrees on a single remuneration program.

Purpose: each partner can credit the total account available on the chip card or pay reward points. Settlements for payments and services between partners are performed by a system running in the background.

Example D. Mutual recognition of reward points by service providers.

Each service provider works with its own remuneration program, however, negotiating with others regarding the recognition of points earned. Well-known examples are the miles between car dealerships and airline campaigns.

Purpose: to support the transfer of reward points by a chip card. Each provider must first accumulate points for themselves, without the possibility of outside interference. Reliable mechanisms must be provided for data transmission.

Example E. Night taxi.

The presence of a ticket for travel by public local or suburban passenger transport at the same time gives the right to travel by taxi picking up late passengers (for example, after 22.00 hours). In the calculations, the taxi fleet must prove the presentation of the ticket. To avoid abuse, taxi use is indicated on the chip card.

Purpose: The remote control application should provide the ability to use, control and calculate this service.

The structure of the chip card of the invention is described in more detail below.

A microprocessor chip card with an additional services function (DU) includes, in particular, a DU container.

The remote control container is an independent application program that exists either alone or along with other applications, based on the chip card platform. The DU container completely contains its own description and can work independently. It can work without the payment function, usually available in the same chip card. In particular, an independent data protection architecture is defined for the DUcontainer, which allows DU applications to use independent protection functions.

Part of additional services (DU) are transactions made by the buyer or client at the terminals of the provider of additional services provider. The provider is interested in tracking these transactions, whether for the purpose of monitoring the system or for collecting statistical and other information. To optimize and unify data structures in the chip card, you should abandon the use of specific application identifiers and switch to the use of unique identifiers (IDs) for the remote control for the entire system. This number can be used by the provider to perform the above functions, eliminating the need to manage their own number schemes.

The security architecture of the remote control uses the specified identifier, unique for the whole system, to obtain derivatives of specific keys of chip cards. The use of specific numbers of chip cards would, in principle, be possible, but it is preferable not to use them, since in the case of installing a remote control container on different platforms, the latter, under certain conditions, use schemes with colliding numbers.

The system operator assigns the identifier to the remote container, and the chip card publisher enters it when creating the remote container. When the remote control is erased, the identifier is destroyed and as a result is deleted from the system. The remote control container is considered remote when there are no remote control applications and the remote control identifier is deleted.

When transferring the entire remote control container from the previous chip card to the new identifier, the remote control is transferred along with the remote control applications. This transfer corresponds to the movement of the remote control container from the old chip card to the new one. After this operation, the previous chip card no longer contains any DUcontainer. The existing DUcontainer in the new chip card during this operation is overwritten and thus deleted. Since the ID of the remote control container moves from the previous chip card to the new one, no conversion of identification numbers is required for providers operating in the background.

Separate remote control applications can be moved between two different remote control containers only under the control of the corresponding remote control provider. When implementing this function, the distribution of the identifiers of the remote control containers and the corresponding remote control applications changes, which under certain conditions must be noted in the background of the provider system.

The remote control container does not contain any signs related to the person. Remote control applications may contain personal data, but their size should be minimized to protect data and make better use of memory. If necessary, remote control applications must store identity data in a system that runs in the background, ensuring that they are linked to the chip card using the remote control container identifier.

An essential distinguishing feature of a remote control container is its support of communication services. Communication services require the ability to access public data, transfer rights to receive payments and services and settle payments and services between different partners. The remote control container must provide these capabilities and, despite this, guarantee application protection as part of internal services.

The so-called remote applications of internal services are applications that operate under the exclusive control of the provider. The provider determines the protection of its application, regardless of any external authority. Without further key transfer, no one can change the remote data from the outside.

For effective communication services, partners must be able to access shared data. Shared data access is provided by multilevel protection mechanisms.

At the first level, sharing is done exclusively through publicly available data transfer fields. Providers can exchange data through these fields without the need to know each other's applications or keys. To write data to these fields, terminals should have corresponding keys, but not for reading. Anyone can read without restrictions. Data exchange between the provider and its partner can be carried out in both directions, provided that each has its own key for recording data. The transmitted data can be generated from the remote control application of the provider's internal services, or vice versa, the provider can take data from the data transfer field into its remote control application of the internal services.

At the second level, the units of value expressed by DU-data are redeemed. The provider enters information about the units of value into the remote control data using a special key for recording. Units of cost can be used up by communication service partners who hold the key to redeem them, which they receive from the provider responsible for the entire system. At this level, partners with different rights gain access to non-public remote data.

At the third level, direct access to the remote control data with the right of recording is provided for all partners involved in communication services. The specified method requires an appropriate degree of trust between participants who are able to unlimitedly change the remote control data.

The data transfer field serves as an interface element for remote applications. The data in the data transmission field is formed by the remote control applications in the remote control container. Data can also be placed directly in the data transfer field if the partner that generated them does not have its own remote control application in the remote control container.

In principle, all applications can use the data transfer field, but only someone who has the right to do so (key) can write. Only recipients who have the right to do so according to the rules, i.e., according to the regulatory framework (K.ts1ek & Vediayopk, K & K.), can read data from the data transfer field. The recipient checks the availability of the transmitted data intended for him and reads them for processing in his own system.

To prevent manipulation of the transmitted data during an open exchange, the data-forming provider provides them with a sign confirming their validity, and the remote control container assigns them a serial number. These elements guarantee a one-time transmission of the message and confirm the origin of the information.

If necessary, the data-forming provider provides the recipient of the transmitted data with the opportunity to verify their validity. In the absence of such a desire, data may be taken on faith; in this case, under certain conditions, their validity is checked according to the corresponding criterion only by performing settlements in the background data-generating system of the provider.

Data can be taken from the data transmission field only once with the receipt of a sign of reality. When fetching data is marked, and they remain (as a copy) in the data transfer field. Such a solution allows, after sampling the data, to confirm the fact of their transmission for a certain time.

The data in the data transfer field contains a date that determines the period of their storage. Any application can overwrite expired data if necessary. When sampling, data in the data transfer field can be marked, as a result of which they are immediately freed for rewriting. If, however, the memory for the transferred data is completely full before the expiration of the storage period of the record with the data to be transferred, the owner of the chip card will have to delete those input messages that he no longer needs on the service terminal.

To simulate remote control applications, 3 operations are specified. These operations operate on DATA. Downloading and uninstalling applications are functions of the remote control container and are not discussed in subsequent paragraphs.

The Acquisition transaction in general terms represents the acquisition of the right to a service or payment and placing confirmation thereof in the remote control data of one of the remote control applications.

The Redemption operation in general terms represents the exercise of the right to a service or payment with full or partial use of the application's remote control data. The indicated operation forms an electronic receipt placed in the data transmission field.

The operation Sampling in general is a sampling of electronic receipt data from a data transmission field for the purpose of further processing (for example, a system running in the background). A copy of the receipt remains in the data transfer field and serves as documentary evidence of the redemption of the receipt.

The acquisition of remote data can only be done by the appropriate provider. The repayment of remote control data can only be performed by the provider who generated it using the Acquisition operation, or the communication services partner who obtained the right to do so. Sampling can be done by any other provider. For communication services without equal access to the remote control data, the partner allows the transition to the Select state. The calculations for the electronic receipt thus obtained can then be carried out through the system operator and the provider system operating in the background. Acquisition and Redemption operations can be performed in one step of the program.

Remote applications with common features can be divided into classes. These classes are the basis of the data structure in the remote container. The provider selects the application class when putting into operation of its application program.

The following application classes are distinguished:

• points memory • ticket • identification card • ticket • data memory

The point memory denotes the class of applications that manage the score value account. Points can be credited to the account and units of value can be withdrawn from it. The provider makes contributions to the account by writing in the memory the new amount of the account balance. The units of value are removed from the account using the Redemption operation, placing an electronic receipt in the memory for the transmitted data as an account document. Access to both of these functions is implemented using two different access keys.

A ticket denotes a class of applications in which there is a cost field, the units of which are redeemed once or repeatedly and, therefore, spent. In the Ticket application class, cost units are credited once.

An identity card denotes a class of applications in which the remote control data certifies the rights to any services. This certificate, as a rule, cannot be expended as a result of its use, however, it ceases to be valid in accordance with a certain criterion, for example, expiration of its validity. Depending on the type of application, it documents the authenticity of the certificate (example: proof of parking rights near your own home) or presentation of the certificate (Example: a trip by taxi that picks up late passengers on a monthly ticket. The chip card issues an electronic receipt. The taxi fleet presents a receipt public or local passenger transport company for proportional settlements). As an additional option, the use of the certificate can be documented on the basis of electronic receipts remaining in the memory for the transferred chip card data.

A coupon denotes a class of applications for intermediate storage in a chip card of (usually short-term) rights to receive payments or services. The indicated electronic coupons are stored exclusively in the memory for the transmitted data of the remote control container. As a rule, the ticket does not use the application that forms it. It is possible to read the ticket from the memory for the transferred data only once, and this reading is documented by the chip card. The reality indicator generated by the DU container can be used by the system in the calculations.

Data memory denotes a class of applications that allow the provider to store data in the DUcontainer that provides the customer, visitor or customer with additional services (for example, the menu with the latest assortment of dishes in the fast food restaurant Rai-Roob, the last numbers that appeared when playing the lottery (digital lotto), privileges in service, lists of candidates). The indicated data is for information only and does not provide the right to receive payments or services from the provider. Access to this data is controlled by the provider.

Each application class is characterized by a specific usage cycle. The table below shows how often the three operations described above are used with respect to the remote control data of each application class. (Caution! Purchasing does not mean Downloading the application, and Fetching does not mean Uninstalling the application).

Table 1. The cycle of use

Memory points Ticket Certificate personalities Talon Data memory Acquisition repeatedly once once once repeatedly * ** Redemption repeatedly repeatedly repeatedly once never Sample repeatedly repeatedly repeatedly once never

* * * In the application class Data memory does not acquire rights, the application only enters data into the application.

In FIG. 4 the above application classes and operations are clearly illustrated by the example of a transaction model.

The protection architecture of the chip card of the invention is explained in more detail below. To ensure protection, the following keys are used.

Table 2. Key Summary Table

Key name Location Owner Description ^To zo Remote control container system operator Key for remote control ^K Ait Remote control container system operator Key for identifying a remote control container ^To SJ VΑЗС Remote control container system operator Key for marking data in transactions KOKves Remote control container system operator The key to obtain the derivative key ^K SK.VES.P1X ^K ^ AZR Remote application provider Write access key to remote control data ^K ^ AZR Remote application provider Read-Only Remote Control Access Key KSK. X Remote control provider provider The key to obtain the derivative key to _CEC ^To bes trading terminal provider Key to identify the trading terminal

The protection architecture is based on the service life of the remote control container, respectively the remote control applications and its levels correspond to the degree of responsibility of the participating authorities. An explanatory diagram thereof is shown in FIG. 5.

Below are some explanations for the structure of the remote control container and the applications contained therein.

The remote control container and specific auxiliary commands for additional services (remote control) are either entered into the chip card by the publisher along with other applications not related to the additional services, or, at the latest, they are installed on the service terminal on the existing chip card platform authorized for this provider.

In the second case, the following mechanism can be used. The system operator agrees with the publisher on the temporary key of _Koz . The publisher opens the chip card with his own key, he knows only, creates the files of the remote control container there, and, in particular, enters the key _K0 into the help file of the data structure ΌΡ_νΑ8. With this option, the system operator can subsequently (for example, when the chip card is inserted into the service terminal for the first time) replace the key _K0 with its own key _K0 , which in this case only he will know. After that, the system operator can also enter other data, for example, the KOC _EEC key generation key, or, having a platform with dynamic memory management, create and delete the files of the remote control applications themselves. Such a system ensures that the publisher after the first use of the chip card will no longer have access to the remote control container, and the system operator will have access only to the remote control container. Thus, the absence of common data structures and any exchange of data with other applications makes the remote control protection architecture independent of other applications installed on the chip card platform.

However, in one of the specific embodiments of the invention, it is proposed to use the first opportunity in which the publisher, on behalf of the system operator, installs the remote control container in the chip card along with all the keys.

The remote control container contains a given data structure, specified access conditions (ACs), and some global data. Global data includes, in particular, the Kzo key for downloading, or deleting DU applications, respectively. The presence of such a key known only to the system operator gives a guaranteed opportunity to download only allowed remote applications. For this, the chip card requires confirmation by the system operator of the right to external access using the key K _o .

When the owner of the chip card wants to download the remote control application on the service terminal, the corresponding provider instructs the system operator to do this for him. When loading the remote control application into the remote control container, the provider transfers the keys K ^ _АЗР and К ^ _АЗР to the system operator, which it enters into the application. The К ^ _АЗР key allows the provider to protect application data from write access and additionally internal data from read access. For this, the chip card requires the provider to confirm the right of external access with the key _KUA8P , that is, the chip card actively monitors the validity of the terminal. After the successful completion of this function, the terminal receives permission to access the remote control application with write permission and access to internal remote control data of the application with read permission. As an additional option, internal identification is possible, i.e. validation of the remote control application (and, consequently, the chip card) by the trading terminal. When using the owner of the remote control chip card with the application, the specified internal remote data can be entered into the application, and accordingly changed at any terminals that have the key К _ЬУА8Р . Therefore, the Acquisition function relies on the update command of the IRΌΑΤΕ KESOYAE record, which must be preceded by confirmation of the right of external access using the key K _ЕУА8Р .

Access with read access to all non-internal data of the remote control application is allowed only if the right to external access is _confirmed with the KUA8P key or the K8O key, or if the system operator correctly entered the PIN code or password. Access protection with a PIN code or password is provided so that the owner of the chip card can view data on terminals or using the electronic money function. At the service terminal, the owner of the chip card can choose, for all applications at the same time, to activate or deactivate the PIN / password protection provided for reading digital data (expressing cost units) or status data.

The K _{8U UA8C key} for marking data read from the data transmission field belongs to the global data of the remote control container. The signature allows you to additionally verify the integrity of the data transmitted during the transaction, if necessary, to transfer them for mutual settlements between communication service partners in a form protected from manipulation. In addition to not necessarily administered by service communication partners the signature in the records issued smart card in step A sample was added signature on the basis of the marking key K y _{A8S occupies 8} and indications managed DUkonteynerom transaction counter. Since, although everyone is allowed to read in the data transfer field, the signature of the chip card is generated by the K _{8U UA8C key} only when the Sampling operation is called (and this can happen only once), this way reveals invalid double-counting of coupons. Each partner in communication services can request from the system operator confirmation of the validity and singleness of transmission of the read ticket. In addition, the system operator can, by checking the signature, confirm the validity of the remote control container.

Supported Platform smart card asymmetric coding methods inside the chip card for labeling as the key K _{occupies 8} at _A8S can be used and a secret key, or similar key may be obtained as a derivative using a secret key forming keys (English name.: Keu Beyegabid Keu). In this case, providers could use public (non-secret) keys for their own signature verification, avoiding the need to consult with a system operator.

Data control container relates global key forming keys (English notation. Rev. beiegabid Rev., K6K _CEC) capable of forming keys K _EEC to control access rights at step repayment for all terminals all providers. (More details on obtaining derivative keys and control will be discussed later). The protection against unauthorized access during the repayment of money-expressing data is approached with different measures than when downloading, or acquiring rights. In this case, instead of the application’s own key, it’s enough to use the global key. This global key is first translated into the application key by obtaining the derivative, and then the terminal key is obtained by re-differentiation. The provider is transferred only the derivative of the shared key related to this application to form its own terminal keys. A brief description of this process is provided below.

The expression tac (k, b) denotes the calculation of the message identification code (from the English Menade AiSheibsabop Sobe) for message b and for the ключаδ-key k, using the data encryption standard ΌΕ8 (from the English Ea1a Yisguurboi 81aibagb). If the message length does not exceed 8 bytes, this corresponds to the encoded value itself (provided that 1СУ = 0). The expression tacp (k, b) denotes the calculation of tac (k, b) followed by equalization of the parity bits. The result k '= tacp (k, b) again is a valid ΌΕδ-key.

The calculation of the terminal keys specified by the applications is performed in this case as follows:

1. Each chip card remembers the key generation key KOC _EEC , the same for all chip cards and kept secret by the system operator. The system operator orders the transfer of this key to the chip card as a personal one. Using this key, you can get all keys of remote applications and terminals as derivatives.

2. The provider wants to enter the remote control application A using the application identifier AGOD = KGOudz.IId. In this case, the system operator calculates, based on the key generation key KOC _EEC and its own application identifier (ΡΙΧ), the specific application key according to the formula:

^K O ^K BES, R1H = tasr _(C K6K Ec R1Ha) and transmits the key provider.

3. This provider, on the basis of the key generation key K6K СЕС _{> Р1Х,} receives for all terminals that use the ΤΚΑΝ8ΡΕΚ (TRANSFER) command with respect to the remote application A, using their terminal identifiers (ΙΌ) their specific derivatives using the formula:

K _CEC = chasr (K6K _EEC , _P1X , terminal)) = tasr (tasr (KOK _CEC , P1X _a ) terminal GO).

The provider remembers these keys in their terminals. In the case when the provider itself does not work on these terminals, it creates keys and distributes them to terminal operators.

4. The DU-chip-card executes the TKALBREK data transfer command only when the command contains the cryptogram C generated by the terminal, which is formed in the memory for the data being sent by the specific data of the message. The chip card itself knows the key COC _EEC and receives from the terminal along with the useful data ya1a and cryptogram C the identifier (GO) of the terminal sent to it, as well as its own application identifier (ΡΙΧ) (accordingly, the chip card itself can know the identifier ΡΙΧ, see this topic. Also, the description of the data transfer command is TKAYZREK. In this case, the chip card can, using useful data, calculate the cryptogram C 'itself using the following formula: tac (tacp (tacp (K6K _EEC , _IX ) GO terminal) |.) _EU . _P | _X. Got-terminal) ya1a) = = tac (K _CEC , na1a) = = C '

Then, the chip card compares the independently computed cryptogram C 'with the cryptogram C computed by the terminal. If they do not match, the transaction is aborted and a failure message is displayed. If they match, the DU chip card executes the TKAIZREC data transfer command.

The different scales of protection measures correspond to the different design of service, respectively, trading terminals (for loading operations, respectively, acquisitions) and simple trading terminals (for repayment operations). To perform the Redemption operation, the terminal must know the _EEC key K and with its help confirm the right of access to the chip card. Attempting a key to _EEC encroached can only use the functions of one given terminal. However, this operation will be recorded by the chip card. The protocol will contain a uniquely defined sequence number, repayment operation and terminal identifier. To regulate access to the remote control data, remote control applications use the security features of the remote control container. The performance of the specific functions of additional services is limited to determining access rights only for participants with these rights.

In general, for each remote control application, publicly accessible memory zones should be provided (for example, for reading data expressed in units of value when using the electronic money function) and individual memory zones of the responsible provider, which it is able to protect against unauthorized access by other persons (for example, internal administration data).

Since chip cards according to the ISO 7816-4 standard do not have any differentiated protection against unauthorized access for individual entries in elementary files (English designation: Е1стсп1аг Рпс5 (ЕР)), then in order to present different classifications of one remote application, you have to use several files, each of which contains one record.

Such a system allows, as shown in FIG. 6, dividing the remote control data into four elementary files, implement for the application classes Memory Points, Ticket, Identity Card and Data Memory differentiated protection against unauthorized access.

These four elementary files contain the following data, respectively, have the following protection:

Table 3. File Summary Table

Field Content Typical use Access protection ΕΕ_ΚΕΥ It contains keys known only to the provider K _b ul8R, ^Κ ΚΥΆ8Ρ (Note: The provider issues a pair of keys for each remote control application and, in an additional version, for each chip card) The provider must use the key Κ _{ρνΑ8Ρ to} confirm its right of access before it can write remote control data to the files EE_UTO, EE_ ΙΧΊΈΗΧΑΕ and EE_ULLIE, respectively, before it can read the data from the file EDITED. The terminal must use the key Κ _{κνΑ8Ρ to} confirm its right of access before it can read the remote control data from the files ЕЕ ΙΝΕΟ, ЕЕ νΑΕ-иЕ ΕΕ_ΙΝΕΟ Non-internal remote control information • Ticket Information • Bonus Program Information • Identity Card Information • Information about parking tickets The content of the indicated data element can only be entered into the memory by the provider (confirming the right of external access by knowing the key Κ _ρνΑ8Ρ .) Data reading should be possible only on terminals with the key Κ _ρνΑ8Ρ or key Κ _8Ο ; or when the owner of the chip card enters the corresponding PIN code (the owner of the chip card can deactivate protection using the PIN code) HER ΙΝΤΕΚΝ L Internal application data Internal counters, account balances, control information, additional keys for: • bonus programs • differentiated discounts • hidden signs of identification • codes The content of the specified data item can be entered into memory and read only by the provider. Protection against unauthorized access is based on confirmation of the right to external access by knowing the key Κ _ρνΑ8Ρ . HER_ULLIE Unit Costs for Remote Application This data element contains accounting units of the cost of the provider application for the following items: • account balance • residual fare • assets • usage counter In the explicit form, only the provider can enter this data into memory (confirming the right of access from the outside by knowing the key Κ _ρνΑ8Ρ ). In implicit value may be reduced command Redemption filed partner provider received from the right to perform this function (using the signature redemption operation using key K _CEC). Reading is performed in the same way as in the file EE ΙΝΕΟ.

This elementary file structure (EE) supports the same differentiated access rights for all application classes.

Since now the same application classes in each case are combined into the corresponding implementation class, which determines the number and size of elementary files, mixing applications that require different amounts of memory can be minimized. The application classes Memory of points and Ticket use the same resources of elementary files ΕΕ_ΚΕΥ, ΕΕ_ΙΝΕΟ, ΕΕ_ΙΝΤΕΚΝΆΕ, ЕЕ_УЛЕЕЕ. therefore, they are combined into an implementation class ΌΡ_ΡΤ. For application classes Identity Card and Data Memory, the elementary files ΕΕ_ΚΕΥ and ΕΕ_ΙΝΕΟ are sufficient, therefore they are combined into the implementation class ΌΕ_ΛΌ. If we consider this situation from a quantitative point of view, then there are objects of the implementation class ΌΡ_ΡΤ in the amount of p and objects of the implementation class ΌΡ_ΑΟ in the amount of a, into which remote control applications of the application classes Memory of Points and Ticket, respectively, Identity Card and Data Memory can be loaded.

Especially for the Talon application class, which should be open for read access to all partners for additional services for their mutual exchange of information, use the data transfer field implementation class. Write access is possible only indirectly by using the data transfer command ΤΚΛΝ8ΡΕΚ, requiring signature with the corresponding key K _ECJ: The specified implementation class consists of exactly one element in the elementary ΕΡ_ΤΚΛΝ8ΕΕΚ file included in the global data control container. The objects of this class are the entries in this file. This implementation class may also be designated ΕΡ_ΤΚΛΝ8ΕΕΚ.

Presented in FIG. 7 implementation classes are inside the remote control container. These implementation classes form the memory model of the remote container.

This memory model can be provided in two of the following ways, the choice of which depends on the platform of the chip card:

- Partitioning the memory area of the DUcontainer into constant sectors.

The publisher determines for the implementation classes ΌΡ_ΡΤ and ΌΡ_ΛΌ the corresponding maximum number (p, respectively, a) of their objects, which he loads into the chip card with the commands for creating the file SKΕΑΤΕ B1E. Objects are designated ΌΡ_ΡΤ ₁ , respectively ΌΡ_ΑΟ ₁ . Remote applications can subsequently be loaded into free, that is, objects not occupied by other remote applications. In this case, only the update command for the υΡΌΑΤΕ КЕСΘΚΌ record is required to download, or to delete the application remote control.

So, the publisher sets the number of possible objects in both implementation classes in accordance with their own needs, which is not necessarily consistent with the actual use of additional services by the owner of the chip card. This memory partitioning is maintained throughout the life of the chip card. The remote control application is loaded into an object belonging to the corresponding implementation class. So, for example, a remote control application representing an identity card can be loaded into an object belonging to the implementation class ΌΡ_ΡΤ, if there are no more free objects in the implementation class ΌΡ_ΑΌ. Linking the remote control application to the object is done by writing three parameters (own identifier (ΡΙΧ) of the remote control application, file identifier (RGO) of the occupied object, full-text name of the application) into the global file ΕΡ_ΌΙΚ of the remote control. Deleting an application corresponds to deleting the indicated three parameters from the файла_ΌΙΚ elementary file and followed by erasing the reading of data from the memory occupied by this application (using update commands of the υΡΌΑΤΕ КРСОКЭ record).

This option finds application when using chip cards with platforms that do not support dynamic generation, respectively deleting the structures of reference and elementary files.

- Dynamic formation of objects of the implementation class.

For each loaded DU Application, using the commands to create the SKK файла file, they form the files necessary for the implementation class on which it is based. When the remote control application is deleted, the help and elementary files it occupies are completely deleted from the chip card, freeing up memory space. In this case, the maximum number of objects in the implementation classes by the publisher is not explicitly determined, but depends only on the available memory capacity of the chip card.

This option requires dynamic memory management from the chip card operating system.

In the proposed embodiment of the invention, the first option is considered, since the second option imposes increased requirements on the existing chip card platform. However, if there is dynamic memory management and the guarantee that dynamic object formation will save more memory than managing it, you can use the existing concept that provides the cardholder with more flexible options.

The data structures and commands below allow you to implement the DUcontainer and the functionality of the client’s chip card in relation to other system components. In addition, remote control operations are defined for typical cases of commercial operations that describe the corresponding interaction between the remote control and the terminal.

To implement this option, the following prerequisites must be met:

- At the trading terminal, any chip card, regardless of its platform, provides the same data and command interface. Therefore, the necessary commands have an unambiguous description of their encoding.

- Service terminals are able to recognize the chip card platform. Therefore, the functions performed can be obtained using specific platform commands. For this reason, these processes are described in part informally. How a specific function will be provided is decided by the chip card manufacturer.

In this regard, in FIG. 7 schematically shows the various implementation classes of the container DU. In FIG. 8 schematically shows the data structure of the remote control container. In FIG. 9 schematically shows the data structure of the implementation class BE_RT. In FIG. 10 schematically shows the data structure of the implementation class BE_AB.

Access to the files of the remote control container in an explicit form is limited by the following access conditions (English designation: Assekk SopbShopk, (AS)):

Table 4. Access conditions

File Admin Read access Write access BE VΑЗ ^To DA NEVER NEVER HER GO ^To DA ALWAYS ^To DA EE B1P ^To DA ALWAYS ^To DA Global keys ^To DA NEVER ^To DA PIN ^To DA NEVER ^To DA HER VΕRZYUN ^To DA ALWAYS ^To DA HER WEU ^To DA ALWAYS ^To DA HER TRA ^ EER ^To DA ALWAYS ^To DA BE X (X = RT ₁ ... RT _p , AB ₁ , ... AB _a ) ^To DA NEVER NEVER HER KEA ’ ^To DA NEVER ^To DA HER UTO ^To DA PIN or К ^ _АЗР or К _ЗО ^K | L \ AZ | - HER ΙΝΊΈΚΝΑΕ ^To DA ^To | .'UASR ^K | L \ AZ | - HER ^ AIE ^To DA PIN or К ^ _АЗР or К _ЗО ^K | A \ AZ | -

Moreover, the specified access conditions have the following meaning:

• ALWAYS (AB ^ from English A1 \\ au5) - command access to the file is always allowed;

• NEVER (ΝΕν from English Ееуег) - command access to a file is never allowed;

• To _DA - before access, the system operator must confirm the right to external access with a KZO key;

• K | _L - _АЗР - before access, the provider must confirm the right to external access with the key K | _LASR ;

• To _RzZAZR - before access authorized by the provider, the terminal must confirm the right to external access with the key K _AAZR ;

• PIN - before access, the owner of the chip card must enter the desired PIN code and send it with the full-text verification command νΕΚΙΕΥ to the chip card;

• PIN or K or K _{IA8R Zo} = Before you can access either the owner of the chip card must enter the correct PIN, or their right to access an external service provider confirms the key K ^ _CBA, or the system operator key COA.

It should be noted that the logical OR operation described above for access rights in operating systems of chip cards, as a rule, is not provided. This circumstance may lead to special costs for the implementation of this operation. (Alternative: a special REAB read command with an implicit security attribute.)

The following formats are distinguished for the data fields inside the records of elementary files: aZsP, Vddg, vSb, Ba1ish, YogshaShppd.

Egtakytpd data elements contain packed / compressed DUdata that can be displayed to the owner of the chip card on the terminal.

For optimal memory utilization, full-text data and binary data are mixed, making it possible to represent them using formatting macros.

All elementary files (ΕΕ) of the DUcontainer are defined in accordance with standard 1ZO 7816-4 as linear formatted elementary files with records of constant length (English definition: Nieag Pheb gesogb P1e5).

The elementary file EE_1B of the data structure (help file BE ^ AZ) consists of one record containing identifiers (1B) of the remote control container.

The elementary file ЕЕ_Б1Р of the data structure (help file БЕ ^ _АЗ ) consists of η _{ϋΙΡ the} number of records. For each remote application loaded into the remote control container, in the elementary file EE-B1P, there is a record in which its extension of its own application identifier (P1X) is recorded (English designation: Рgorpe1agu 1bebbyeg Ex1epyop (Р1Х)) and its physical memory location (identifier (Е1Б) file BE_X, into which the application is loaded). The extension of the application’s own identifier (P1X) allows, as a conditional number, to determine, for example, the application and the provider to which it relates.

The input data is dynamically placed in the file ΕΕ_ΌΙΒ by the service terminal of the system operator. Records that do not contain the entered data are formed using the empty object ΤΕν '61'.

When loading a remote control application, first a search is made for a free memory area in a suitable implementation class, certain remote control data is entered here and, finally, a new record is created in the elementary file ΕΕ_ΌΙΒ.

When uninstalling the application to the ΕΕ_ΌΙΚ elementary file. it is necessary to enter the empty object ΤΕν accordingly.

The elementary file ΕΕ_νΕΡ3Ι0Ν of the data structure (help file ΌΕ_νΑ3) consists of one record containing the version number of the remote control container.

The version number can be used by the terminals in order to distinguish from each other different options of remote control containers and / or different versions of software.

The elementary file ΕΕ_3Εφ of the data structure (help file ΌΕ_νΑ3) consists of one record containing the number of the next input message in the data transfer field.

The serial number is read using the auxiliary data transfer command ΤΡΑΝ3ΕΕΡ .. After this operation, the specified command generates a record in the data transfer field (elementary file ΕΕ_ΤΚΑΝ3ΕΕΡ.), Into which, in particular, the serial number from the elementary file ΕΕ_3Εφ goes. Together with the sampling team ΤΑΚΕ, which provides a one-time sampling of each record from the data transmission field and documents this sampling using a signature by the serial number, such a system allows one-time sampling of the (originals) of coupons, receipts, respectively.

The memory for the transmitted data is described in more detail below.

The memory for the transferred data, formed inside the remote control container, includes πγ _ερ τκ _ΑΝ 8 _ΕΕ κ records. The contents of the records of this file are the transmitted data generated by the data transfer command ΤΡΑΝ3ΕΕΡ .. The memory for the transmitted data serves both for the exchange of data between remote control applications and for storing remote control data of the Talon class.

The memory for the data being transferred does not have a restriction on data sampling, however access to it with write permission is possible only with the help of the data transfer and data retrieval commands ΤΡΑΝ3ΕΕΡ related to the additional services function. and ΤΑΚΕ.

Filling data fields with data transfer command ΤΡΑΝ3ΕΕΡ. occurs using the algorithm available in the chip card of the last of the recently used ones (the English designation is 1k1 gesepIu ikeb). The oldest record in the file can be determined by finding the smallest value in the first 2 bits of the record.

Data fields can be marked with the selection command ΤΑΚΕ in the memory for the transmitted data as selected and / or deleted. In any case, the deletion of data from memory for the transferred data occurs as a result of overwriting them with new data.

Each entry in the memory for the data being transferred includes, for example, the expiration date of its storage period, terminal identifier (GO), its own application identifier (ΡΙΧ), serial number and other possible data.

Each elementary file ΕΕ_ΙΝΕ0 inside the directories of help files ΌΕ_Χ (where X = РТ ₁ , ..., РТ _р , ΑΟ ₁ , ..., ΑΌ _α ) consists of one record containing the expiration date of the storage period, as well as general remote control data DUpplications. For example, it may indicate the type of ticket (one-time or for several trips) or the departure point. However, the file ΕΕ_ΙΝΕ0 must contain at least one full-text application name that can be read during the View Remote Application operation. Data that is not intended for public use, the provider must protect using appropriate external coding algorithms.

The named elementary file can be read when obtaining the right of external access using the keys Κ ₃₀ or К _к ^ _3Р , or when the owner of the chip card enters the corresponding PIN code in case of activation using this protection number.

Each elementary file

ΕΕ_ΙΝΤΕΡΝΑΕ inside the directories of the help files ΌΕ_Χ (where X = PT ₁ , ..., PT _p , ΑΌ ₁ , ..., AE _a ) consists of one record, which may contain the provider’s internal DU data regarding the DU applications loaded by it. Neither the owner of the chip card, nor any other provider can read this internal data.

Each elementary file ΕΕ_νΑΕυΕ inside the directories of the help files ΌΕ_Χ (where X = ΡΤ ₁ , ..., RT _p , ΑΟ ₁ , ..., ΑΌ _α ) consists of one record, which may contain a field expressed by integer numerical values of DUdata. This elementary file can be read when obtaining the right of external access using the keys Κ ₃₀ or Κ _κνΑ3Ρ , or when the owner of the chip card enters the corresponding PIN code, respectively, of the required password in case of activation using this protection number.

The following key fields are used by the remote control or the remote control application. The following description proceeds from the use case for encryption of only the data encryption standard ΌΕ8, i.e. all keys of the remote control are 8-byte keys of 8 bytes (including the parity bit).

Inside the remote control container and inside the remote control application, you can use the following keys using the appropriate key identifier KS (from the English Keu Iep11yet is the key identifier):

Table 5. Keys for remote control

Key KS key identifier ^K 8O '00' ^K Ait '01' ^K 8Yu \ A8S '02' COC ^ s '03'

Each key is associated with a counter of attempts of misuse, which registers unsuccessful attempts to gain access using this key, and blocks further use of the key when the limit of attempts specified in this counter is reached.

Inside the remote control application, you can use the following key identifiers (CS) to access the following keys:

Table 6. Remote Application Keys

Key KS key identifier ^K b \ A8P '04' ^K \ A8P '05'

Each key is associated with a counter of attempts of misuse, which registers unsuccessful attempts to gain access using this key, and blocks further use of the key when the limit of attempts specified in this counter is reached.

The DU-container contains a personal identification number or password (PIN) used by the UTECU verification team to identify the owner of the chip card. This PIN number or password is associated with the counter of attempts of misuse, which registers each case of incorrect entry of this number or password and blocks the comparison of the entered number or password with the set upon reaching a certain limit of attempts. The specified lock can be removed by the system operator using the appropriate administration commands. If the PIN number or PIN is entered correctly, the counter resets the reading.

The following parameters of the DUcontainer can be selected by the chip card publisher based on the available space in the chip card platform and in accordance with their own wishes.

• p Maximum number of objects of the implementation class ΌΕ_ΡΤ = maximum number of remote control applications in the application classes Data memory and Ticket, which can be simultaneously loaded into the remote control container;

• a Maximum number of objects of the implementation class ΌΕ_ΑΌ = maximum number of remote control applications in the application classes Identity card and data memory that can be simultaneously loaded into the remote control container;

• n _ssh Maximum total number of objects: n _wK = p + a.

The number of entries in the elementary file ΕΕ_ΌΙΡ. equal to n _s | <:

• ητ _Εί · _{ΤΚΑΝ8ΕΕΚ The} number of entries in the elementary file ΕΕ_ΤΒΑΝ8ΕΕΒ.

The size of memory needed based on the size of the elementary files described above:

Global data of the remote control container:

Data transfer field Providers' own data:

BG_YU

ΕΓ_ΏΙΚ

ΕΓ_νΕΚ8ΙΘΝ

Ι ·· .1 ·· 81 -. (.)

Global keys, PIN ΕΓ_ΤΚΑΝ8ΓΕΚ

Ε1_ΚΕΥ

ΕΕ_ΙΝΕΟ ΕΕ_ΙΝΤΕΚΝΑΕ

Ε1 _ \ '. \ Ι.ΙΤ.

Byte

9 * (p + a)

64 + 2

48 * ηΐΕΓ_ΤΚΆΝ5ΕΕΚ (p + a) * 32 (p + a) * 32 p * 10 p * 3

When choosing, for example, for the parameters a, p and t _{EE ΤΚΑΝ81ΕΚ} , the following values, we obtain the following minimum memory size required for the DUcontainer (without memory required for auxiliary commands):

Parameters Memory requirement p = 8, а = 3, ηΐΕΓ_τκΑΝ8ΓΕκ = 15 2030 bytes p = 10, а = 5, ηΓΕτ_τκΑΝ8ΕΕκ = 20 2758 bytes

The maximum memory requirement is probably about 10% higher than the minimum requirement.

Below is a more detailed description of the teams proposed in the invention of the chip card.

The write read command чтения ΚΕΟΘΒΌ is used to read data from linear elementary files. The chip card responds with the contents of the record. Reference to the elementary file Ε1 provides a brief identifier for the file, Eng. designation 81y1 Eye Yepyyet (8ΕΙ).

The status code '9000' indicates the successful execution of the command; any other code is evaluated as an error.

The record update command υΡΌΑΤΕ ΚΕSOCO is used to enter data into the records of the linear elementary file Ε1. The command message contains a link to the elementary file Ε1, record and data.

The response of the chip card contains a status code. Status code '9000' indicates successful completion of the command. Other status codes indicate an error.

The command to call a random number CET NEXT will require a random number from the chip card. A random number is used in connection with the dynamic confirmation of the right of external access in the external identification command EXTENUAE AITNEKPSATE.

The chip card response message contains a random number of 8 bytes in length and a status code. The status code '9000' indicates the successful execution of the command. Other status codes indicate an error.

The external identification command ΕΧTECHAiNiNiT1CATE allows you to confirm the access right of the terminal to the chip card. The EXTENUE AETNEXT1CATE command is used as part of remote control applications to confirm the access rights of the system operator and provider. The EXTINUTE ATTACHED1CATE command sends a cryptogram to the chip card, which the terminal must first generate by encoding a random number. The chip card compares the cryptogram with a control value, which it itself calculates in the same way. If both values coincide, the chip card notes within itself that the conditions for confirming access rights for this key are met. If the comparison result is negative, the chip card responds with a status code of Not authorized and reduces the number of attempts in the internal counter of incorrect use attempts by one unit. When the counter reaches a value of zero, the chip card goes into the Identification state, which blocks any further execution of the external identification command EXTENUAET AETNEXT1SATE.

The chip card response message contains a status code. Successful execution of the command and confirmation of the terminal's access right to the chip card shows the status code '9000'. All other status codes indicate an error.

The STENUAE AITNECT1CATE internal identification command is used to enable the terminal to verify the validity of the remote control container. For this purpose, the chip card calculates a cryptogram based on the initial data received from the terminal. The terminal, for its part, creates a cryptogram and compares it with the value received by the chip card. If they coincide, the terminal can accept the validity of the DUcontainer.

The response of the chip card contains a cryptogram and a status code for executing the command. Successful execution of the command shows the status code '9000'. All other status codes indicate an error.

The WESHEU verification team is used to verify the access rights of the owner of the chip card by his personal identification number or password (PIN). The command transmits PIN number or password data to the chip card in unencrypted form, and here they are compared with the control value stored in the memory. If the entered and stored values match, the PIN access condition is considered fulfilled.

The chip card response message contains a status code. Status code '9000' indicates successful execution of the command. Other status codes indicate an error.

The data transfer command SAME creates an input message in memory for the data being transferred. Three operating modes are defined for this command:

1. Formation of the input message in the data transfer field by decreasing the values in the elementary file EE_UAJE of the application of the class Ticket or Point counter.

2. Formation of the input message in the data transfer field by generating receipts in the applications of the class Identity card.

3. Formation of an input message in the data transfer field by forming a coupon in applications of the Coupon class.

The card selects the operating mode automatically. When executing a command within the selected help file, the application first checks for the presence of an elementary file EE_UAJE. If this file is present, the chip card executes the command in the first mode, in other cases - in the second mode. If the application help file within the DUcontainer is not selected, use the third mode.

When calling the data transfer command TKA№EEV, the terminal supplies the chip card with the following data:

• Current date • The expiration date of the input message in the data transfer field • Identification of the terminal that forms this input message • Useful data for the data transfer field • Own identifier (ΡΙΧ) of the remote control application (only for mode 3) • Number of deductible units (only for mode 1) • Message identification code (MAS) according to the above data, serial number and number of the remote control container.

When calling the data transfer command TKA№EEV, the chip card performs the operations in the following sequence:

1. Search for a free input message in the memory for the data being transferred (the listed listing shows, in descending order, the priorities, taking into account which the existing input messages should be rewritten: The message is marked as deleted,

The message is marked as read and the expiration date has come, the expiration date has come).

2. Adding to the terminal data its own identifier (ΡΙΧ) of the remote control application in modes 1 and 2.

3. Adding a serial number to the data from step 2 of the program.

4. Adding to the data from step 3 the program identifier (GO) of the remote control container.

5. Preparation of the key CSC forming _EEC keys _R1H formation of XK wrenches _EEC by encoding own identifier (R1H) DUprilozheniya.

6. Preparation of the key K from the key formation _EEC XK _EEC keys _R1H by encoding the identifier (GD) terminal.

7. The formation of a message identification code (MAC) according to the data from step 4 of the program.

8. Comparison of the message identification code (MAC) from step 7 with the message identification code (MAC) of the terminal. If the values do not match, the chip card interrupts this function and reduces the number of attempts in the counter of attempts to use the key to generate keys KSK _EES incorrectly.

9. For mode 1: control of the field of values (units of value) of the elementary file EP_UAE in the directory in which the application is loaded. If there are insufficient units in the indicated field, the chip card interrupts the function in this place. Otherwise, the number of units of value in the field of this application is reduced by the corresponding amount.

10. Composing a team message.

11. The increase in the content of the elementary file EP_8EO by one unit.

With such a system, the issuance of an information record in the response is not needed. You can continue to assume that the record number is known.

The fetch command ALSO provides the following modes:

• Sampling while marking that the data has become invalid.

• Sampling without the above mark. Data continues to be valid.

The command message includes fields with the identifier (GO) of the terminal, the application's own identifier (P1X), and a random number generated by the terminal.

A custom identifier (P1X) in a command indicates a sample application. It may differ from the own identifier (P1X) of the record being read. It serves solely to obtain the derivative key K _EEC of the sampling trading terminal.

The response message of the chip card contains a cryptogram C ₁ with a key K _{8U UAZ} according to the data in the data message specified in the command message and the identifier (GO) of the remote control container, a cryptogram C2 with a key K _EEC that selects the terminal using C ₁ and a random number from team message. The response message further comprises a status code. The derivative key K _{EEC is} obtained as described above. Using a cryptogram with the key K _{EEC, the} DUcontainer in implicit form proves its validity. Using cryptogram C, a calculation is made to prove the validity of the remote control container and the information is sampled once (since cryptogram C is formed on the basis of the serial number, bit of the record selection from the data transfer field, and the identifier (GO) of the remote container), which can be verified by the system operator.

The status code '9000' indicates successful execution of the command. Other status codes are interpreted as errors.

It should be assumed that the system operator requests one identifier (AGO _UAZ ) of the application in accordance with the standard 18O / 1ES 7816-5. More precisely, it requests a registered by the application provider identifier (IGO _νΑ3 ) having a length of 5 bytes for the additional services system.

The identifier (AGO _UAZ ) of the application of the data structure catalog (help file ΌΕ_νΑ8) should look like this ^: AGOUAZ = YAGOA8 ' ^P1X BE_UA8.

The command message contains, for example, fields with an expiration date, terminal identifier (GO), transaction data, an operating mode field (containing, for example, a proprietary identifier (P1X) in mode 3), as well as a cryptogram.

The cryptogram is calculated using the _EEC key K, the data used to generate the message identification code (MAC) includes, for example, transaction data and the terminal identifier (GO).

The response message of the data transfer command TYAZEZEEYA consists in the positive case of a data field 8 bytes long and a status code '9000' 2 bytes long. Response messages with status codes other than '9000' are interpreted as an error code. The data field of the response message contains, in the absence of an error (i.e., in particular, if the cryptogram in the command message is correct), the cryptogram of the command message encrypted with the key _EEC . In this way, the remote control container implicitly confirms its validity (instead of internal identification using the identifying key K _Ait ).

The fetch command is also used to fetch objects from the implementation class.

EE_TIAAY8EEE. Technically, the execution of this command means reading the indicated record from the file EP_TKAY8REY, and this record remains in the file marked selected / read until its place in memory is needed to enter new messages. From a technical point of view, anyone can use the TAKE command to read records, but from the point of view of standards (K&K), only the provider for whom this record is intended should do this.

For the fetch operation, the following scheme can be adopted. A provider who is about to sample a ticket or receipt looks through the entire memory for the data being transferred in search of a suitable information record (for example, using the search command 8ЕЕК, or by reading each record explicitly). In any case, the record is read and, if necessary, checked its contents.

Each remote control application A receives, in accordance with the rules, its own identifier (P1X _A ) of 3 bytes in length, which allows it to be uniquely identified inside the remote control using the identifier (AGO _a ) of application A according to the formula: AGO _a = KGOulkh'RShd. After the help file BR_UA8 of the data structure is selected, the file selection command 8EBEST IS MORE <P1X _A > can be used to select the directory in which DU Appendix A. is located

The expression IRBATE KEU (KGO, K) denotes a platform-specific command for the chip card that replaces the key with the KGB key identifier with the new value of key K.

Before the owner of the chip card can use at the DU trading terminals an application of one of the BRRT or BR_AB implementation classes (which corresponds to the application classes Memory of points, Ticket, Identity card or Data memory), this application must be downloaded to the DUcontainer on the service terminal of the corresponding provider. In principle, a variant is also possible in which the publisher of the chip card, on behalf of some provider, and any system operator, when installing the remote control container, loads one or more remote applications into it. Such a loading process is a special case of this description.

The process of downloading a remote application is as follows:

1. The owner of the chip card inserts the remote control chip card into the service terminal.

2. The service terminal checks for the presence of the remote control container using the following commands:

• FILE SELECTION: 8EBEST 13E <Λ [^ _VΛ8 > (error message if it is not possible to select a container).

• READING THE RECORD: KEAB KESOKB <8ΡΙ of the EP_GO file, 0> (reading the number of the DUcontainer).

In an additional embodiment, the validity of the remote control container is checked. For this, the service terminal requires the DUcontainer internal identification:

• INTERNAL IDENTIFICATION: YUTEKYAI AITNEKHPSATE <random number, KGO from K _AiT >.

The service terminal checks the response and stops the operation in case of an error, giving an error message.

3. The service terminal provides the owner of the chip card with a choice of how many additional options. One of them is Downloading a remote application. The owner of the chip card selects it. Then the service terminal starts the operation View Remote Control Applications, showing the owner of the chip card all the Remote Control Applications that it can download, and waits for it to be selected. The owner of the chip card selects some remote application A from the implementation class BR_RT or BR_AB.

4. The service terminal during the operation. Selecting the remote control application checks the remote control, determining whether the selected remote control application with its own PEX identifier has already been loaded into the chip card. In this case, it gives an error message. In the absence of this application in the chip card, the service terminal checks if there is still a free object in the DUcontainer that corresponds to the implementation class of the DU application A. This check is performed by searching (for example, using the search command 8ЕЕК) for a free record in the elementary file ΕΕ_ ^ [Ε. If there is no free recording, an error message is received. If there is such a free record, it contains the identifier ΡΙΌ _ϋΡ _ _{Χ of the BR_X} file (directory) into which no remote application is loaded.

5. The next free object of the implementation class corresponding to the DU-application A is occupied by the D-application A. In this case, the service terminal first asks the provider in the OGGNpe mode (for example, using the provider's secure access control (8AM)) two keys К _ЬУА8Р and К _КУА8Р and assigns them to a new remote control using the following commands:

• FILE SELECTION: 8BEST RGOE <RGO _S p_x>

• Call random numbers smart card: SETH SNAIEEMbE • External identification: EHTEKYAI AITNEHPSATE <K _LP (random number), from the CLC to the _LP>

• KEY UPDATE: IRBATE KEU <KGO ^from K | D-A8P · ^K LUA8P>

• KEY UPDATE: IRBATE KEU <KGO ^{from K} VUA8R>

• CALLING THE RANDOM CHIP CARD NUMBER: SET FOR YOU • EXTERNAL IDENTIFICATION: ΕΧΤΕΚΝΑ1. ΑυΤΗΕΝΤΙίΑΤΕ <K _L at _AZ p (random number), ΚΙΌ of K _UA 8 _P>

• RECORD UPDATE: υΡΌΑΤΕ SAND!) <8ΕΙ of the file ΕΕ_ΙΝΕΟ from the file (directory) ΌΕ_Χ, data>

• RECORD UPDATE: υΡΌΑΤΕ ΚΕSOKE <8ΕΙ of file ΕΕ_ΙΝΤΕΚΝΑΕ from file (directory) ΌΕ_Χ, data>

• Optional (initiation): RECORD UPDATE: υΡΌΑΤΕ ΚΕίΟΚΌ <8ΕΙ of the file ΕΕ_νΑΕυΕ from the file (directory) ΌΕ_Χ, data>

6. After successfully writing information to the elementary files (ΕΕ), the service terminal performs the operation of entering the remote control application: ΕίπΙπίβ νΑ8-Αρρ1ίΕαΙίοη ^ IT, ΕΙΌ _ϋΕ _ _Χ >, connecting the file ΌΕ_Χ with its own identifier (Р1Хд) of the application, thus allowing the command to be executed 8ΕΕΕΟΤ ΕΙΕΕ file selection using the application’s own identifier (ΡΙΧΑ) (after preliminary selection using the 8ΕΕΕίΤ ΕΙΕΕ AP command) · .....).

The mechanism provided by the memory for the transferred data can be used, for example, by providers who want to provide internal and communication services without their own help file structures. In this case, the owner of the chip card is not required, in particular, before using the remote control application, first download it on the service terminal. Instead, he can receive a ticket or receipt on the trading terminal and receive compensation for them on another terminal (using the fetch operation), or simply present this ticket, respectively, a receipt (read operation). Thus, the loading of the remote control application of the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ occurs implicitly as a result of entering the remote control data, and accordingly reduces to it. In this regard, reference should be made to the later description of the operation Acquisition of the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ.

The following describes the sequence of operations for entering the remote control application. When the remote control application is loaded into the remote control container, the terminal does not know its physical location, in which file ΌΕ_Χ, where X = PT _b .., PT _p , ΑΌι ..., ΑΌ ₃ , the remote control application is downloaded and whether it is loaded at all. From the point of view of the chip card manufacturer, there are two possible implementation methods to be considered separately, and it is necessary, in particular, to take into account compatibility with the Central Credit Administration standard стандар.

The first case: access to the elementary file ΕΕ_ΌΙΚ is possible. In this case, the following prerequisites must be met:

• In the chip card platform, as a standard, there should be an elementary directory ΕΕ_ΌΙΚ file (for example, in the data structure of the help file ΌΕ_νΑ8), in which the application identifiers ΑΙΌ are distributed by the identifiers ΕΙΌ of those ΌΕ_Χ files in which the remote control applications are currently located.

• This elementary file ΕΕ_ΌΙΚ should be readable by everyone (access condition (AC) of the read command записи ΚΕίΟΚΌ: Α1Α \ '- ALWAYS).

• When the system operator loads the remote control application A, which has its own identifier REU, into the free (unused) help file ΌΕ_Χ, i.e. when making entries in the existing elementary files of this help file ΌΕ_Χ (not when creating a new file with the ίΚΕΑΤΕ ΕΙΕΕ! command), it should be possible, using the update command of the υΡΌΑΤΕ ΚΕίΟΚΌ record, to provide the ΕΕ_ΌΙΚ file with the extension in the form of a record of this own identifier REY, indicating the identifier ΕΙΌ _Χ on named help file ΌΕ_Χ. Therefore, the access condition AC of the record update command υΡΌΑΤΕ ΚΕίΟΚΌ should provide external identification with the key Κ _8Ο .

• When transmitting the file selection command 8ΕΕΕίΤ ΕΙΕΕ <RAY> to the chip card, after first selecting the help file ΌΕ_νΑ8 of the data structure, it should be possible to directly select the help file ΌΕ_Χ into which the remote control application A is loaded.

• When deleting at the service terminal, at the request of the owner of the remote control application application chip A, loaded into the help file ΌΕ_Χ and the elementary files located below it, the corresponding files are not erased by the delete file command ΌΕΓΕΤΕ ΕΙΓΕ, but only write down dummy values from above. After this, it should be possible to delete the REY entry from the ΕΕ_ΌΙΚ file (more precisely, a pair consisting of its own identifier РИХ _Α and a link to the help file ΌΕ_Χ), for example, by updating the υΡΌΑΤΕ записи record with preliminary confirmation of the right of external access using the Κ _8Ο key.

• Since the number of help files ΌΕ_Χ is constant, the number of records of elementary files ΕΕ_ΌΙΚ is also known. If it is possible to implement such an approach, we can draw the following conclusion:

• The choice of the remote control application by the file selection command 8ΕΓΕΟΤ ΡΙΕΕ REU immediately after selecting the help file ΌΕ_νΑ8 of the data structure of the remote control is possible. The second case: access to the elementary file ΕΕ_ΌΙΚ is not possible.

If there is no отсутствии-файла file in the chip card platform, or if there is no read and write access to this file described in the previous section, the файле-ν в8 help file of the DUcontainer data structure must contain an elementary file ЕЕ ^ А8ПГК, in which system operator fed explicitly commands update the record OTBATE KE ^ CL (after prior approval of the right to external access key Κ _8Ο) communicates own ID R1H _a loaded control applications with their physical mestonaho deniem in memory in the background BE_H file. It should be possible to read and delete entries from the file EE ^ A8NSH similar to the previous description.

The operation of entering the remote control application takes place in the following sequence:

The DU-application A with its own identifier P1X _A applications are pre-loaded into a free help file BE_X having the EGB identifier x of _it . Service Terminal celebrates record number with the ID NO _s. · _X file. Then follow the command:

1. FILE SELECTION: 8EEST EPE <ΛΙβ _νΑ8 > (Error message if it is not possible to select a container).

2. CALLING THE RANDOM NUMBER OF CHIP CARD: SET HERE

3. EXTERNAL IDENTIFICATION: EXTEXT AND EXTENSION <Κ _8Ο (random number), ΚΙΩ of Κ _8Ο >

4. RECORD UPDATE: SENATE KEOTIL <8EI of the file ΕЕ_ ^ IΚ from the file (directory) БЕ_Х, record number with identifiers ^ЕI ^^ Е_X ^{, РИХ} Α ^{, ΕΙ} Οι.) Ϊ́ · χ>

Remote applications of the implementation classes ^ Е_ Е or БЕ_АБ can be deleted only at service terminals (since they are at the disposal of the system operator) at the request of the owner of the chip card, remote applications of the implementation class ЕЕ-ТКАЫ8ЕЕК can be deleted anywhere and by anyone. When deleting, one should distinguish between DU-applications of the implementation classes ^ Е_ΡΤ and БЕ_АБ and, accordingly, the implementation class ЕК_ТКАЫ8ЕЕК.

Removing such a remote control application related to the implementation class ^ Е_ΡΤ or БЕ_АБ is performed in the following order:

1. The owner of the chip card inserts the remote control chip card into the service terminal.

2. The service terminal checks for the presence of the remote control container using the following commands:

• FILE SELECTION: 8EEST EPE <ΑΙΌ _νΑ8 > (Error message if it is not possible to select a container).

• READING THE RECORD: KEAB KESS) 1st <E_GB> (reading the identifier of the DUcontainer).

3. The service terminal provides the owner of the chip card with a choice of how many additional options. One of them is Removing a remote application. The owner of the chip card selects it. Then, the service terminal starts the operation View Remote Control Applications, showing the owner of the chip card all remote control applications of all implementation classes loaded into the remote control container, and waits for it to be selected. The owner of the chip card selects Application A from the implementation class ^ E_ΡΤ or BE_AB. Suppose that the object into which the remote control application is loaded has the designation BE_A.

4. After selecting the BE_A object, the service terminal confirms its right of access with the following commands:

• FILE SELECTION: 8EEST EPE <P1X _A >

• CALLING THE RANDOM NUMBER OF CHIP CARD: SETHNESS EXCEED • EXTERNAL IDENTIFICATION: EXΊΤΕΝΑΙ. АυΤНΕХΤIСАΤΕ <Κ _8Ο (random number), ΚΙΌ of Κ _8Ο >

5. Then, the contents of the files are deleted from the object, the help file OE_A (for elementary files ΚΕ ^ ΚΕΥ, ΕЕ_INΤΕΚХА ^ and ЕЕ ^ АиЕ the key Ε _{ρνΑ8Ρ is necessary} , therefore the system operator first deletes it) using the following commands:

• KEY UPDATE: SENATE ΚΗΥ <ΚΙΌ of 00 ... 00>

• KEY UPDATE: SENATE ΚΠΎ <ΚΙΌ of Κ _ΕνΑ3Ρ , 00 ... 0>

• CALLING THE RANDOM CHIP CARD NUMBER: SLEEP SET ^^ ΕNСΕ • EXTERNAL IDENTIFICATION: EXΊΤΕΝΑΙ. АυΤНΕХΤIСОΤΕ <К _ЬУА8Р (random number), ΚΙΌ from Ε _ρνΛ8Ρ >

• RECORD UPDATE: SENATE КЕί ', ’ΟΚΟ <8ЕI of the file ΕЕ_ИХЕΟ from the file (directory) БЕ_А, 00 ... 00>

• RECORD UPDATE: SENATE КЕί'.ΌΚΟ <8ЕI of the file ΕЕ_INΤΕΚNА ^ from the file (directory) БЕ_А, 00 ... 00>

• RECORD UPDATE: SENATE КЕί'.ΌΡΗ <8ЕI of the file ЕЕ ^ АиЕ from the file (directory) БЕ_А, 00 ... 00>

6. After the information is successfully written to elementary files (EE), the service terminal finally deletes the entered application data from the EE_PGK file using the following commands:

• FILE SELECTION: 8EEST EPE <ΑΙΌ _νΑ8 > (Error message if it is not possible to select a container).

• RECORD UPDATE: SENATE КЕί'.ΌΡΗ <8ЕI of the file ЕЕ_Н! К from the file (directory) БЕ ^ А8, record number with ΕΙΗ _{Ρ) Ε} _ _А , 00 ... 00, ЕГБде_ _а >.

As a result, the connection of the identifier Р1Х _{А of the} loaded remote application with the object, the help file EE_A is interrupted and the execution of the file selection command 8ЕЕСТЕ ПЫЕ using the identifier Р1Х _А becomes impossible.

Let us now consider the removal of the DU application of the implementation class YESEKA ^ EEK.

In accordance with the norms (K & K) removal

Implementation class remote control applications

ΕΕ_ΤΡΑΝ8ΕΕΡ should be possible only if expressly expressed by the owner of the chip card at the trading or service terminal (even if from a technical point of view this could be done on both terminals). In particular, deleting an object from the implementation class ΕΕ_ΤΡΑΝ8ΕΕΡ is necessary when there is no more space left in the memory for the transferred data to accommodate a new object (for example, a coupon or receipt). Deletion is always performed directly using the auxiliary fetch command ΤΑΚΕ. This command only marks any object as remote, allowing you to overwrite it using the subsequent auxiliary data transfer command ΤΡΑΝ8ΕΕΡ. Removing the named DU-application is performed in the following order:

1. The owner of the chip card inserts the remote control chip card into the terminal, which can show the contents of the implementation class ΕΕ_ΤΡΑΝ8ΕΕΡ (special case of the operation View remote control applications).

2. The service terminal checks for the presence of the remote control container using the following commands:

• FILE SELECTION: 8ΕΕΕΕΤ ΡΚΕ <ΑΙΌ _νΑ3 > (Error message if it is not possible to select a remote control container).

• READING THE RECORD: ΡΕΑΏ ΕΕΕΟΕΟ <8ΕΙ from ΕΕ_ΙΌ, 0> (reading the identifier of the remote control).

3. The service terminal provides the owner of the chip card with a choice of how many additional options. One of them is Removing a remote application. The owner of the chip card selects it. Then the service terminal starts the operation View Remote Control Applications, showing the owner of the chip card at least the remote control application of the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ, and waits for it to be selected. The owner of the chip card selects an object of this implementation class containing a coupon, respectively a receipt. Suppose that the object has the application number A. Application. The owner of the chip card confirms his choice.

4. The terminal marks the entry with the application number A as deleted, passing the application number A, a random number calculated by it, its own identifier ΡΙΧ and the identifier (GO) of the terminal using the fetch command ΤΑΚΕ:

• SAMPLE: ΤΑΚΕ <A, random number, ΡΙΧ, GO terminals

Now marked as deleted entry is again ready to accept the data of a new coupon or receipt.

The following describes the sequence of operations when choosing a remote application.

If the remote control application A of the implementation classes ΌΕ_ΡΤ or ΌΕ_ΑΌ was loaded into the remote control by the operation of loading the remote control, then it can be selected by the terminal in two stages. First, the remote control container is selected, and then the remote control application is selected with its own identifier Р1Хд using the following commands:

1. FILE SELECTION: 8ΕΕΕΕΤ ΕΚΕ <AGO ^ ₃ > (Error message if it is not possible to select a container).

The service terminal can check the validity of the remote control container. For this purpose, the service terminal will require the internal identification of the remote control container using the commands:

• READING A RECORD: ΚΕΑΌ ΕΕΕΟΕΟ <8ΕΙ from ΕΕ_ 0, 0> (reading the identifier (GO) of the remote control container).

• INTERNAL IDENTIFICATION: ΙΧΤΕΕΧΑΕ ΑΕΤΙΙΕΧΤΙνΙΕΑΤΕ <random number, WHO from K _Aig >

The service terminal checks the response and stops the operation if the answer is incorrect (with an error message).

2. FILE SELECTION: 8ΕΕΕΕΤ ΡΙΕΕ <Р1Х ^ (Error message if the remote control application A is not loaded into the remote control container).

A trading terminal (which does not have a key for generating keys ΚΟΚΑΕΤ) can indirectly verify the validity of the remote container by checking the validity of the remote application A. The fact is that the remote application could only be downloaded on the service terminal, which checked the validity of the remote container during the download process. Validation of the remote control application A can be reduced to the verification by the trading terminal whether the remote control container has the key ключ |. _νΑ3 ι- or Κ _κνΑ3Ρ to the remote control application A. The trading terminal can verify this, for example, using the command:

• INTERNAL IDENTIFICATION: ΙΝΤΕΚΝΑΕ ΑΕΤ1 ΙΕΧΤΙνΙΕΑΤΕ <random number, KGO from K | _LAZ |, or ^Κ Κ.νΑ8Ρ>

To check whether the remote control is loaded into the remote control, you can try to select it; an error response message after the file select command 8ΕΕΕί’Τ ΕΙΕΕ will indicate its absence.

The choice of the remote control application of the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ occurs implicitly as a result of the operation Viewing the remote control applications and storing data in the terminal. Since the terminal knows the record number of each displayed object from the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ, using the record number, by reference to this number, you can select any object for further processing.

The following describes the procedure for viewing the remote control.

During the operation View Remote Control Applications, the service terminal displays a list of all

Remote control applications related to the implementation classes ЕЕ_РТ, ΌΕ-ΑΌ and ЕЕ_ТАЖЕЕР. The trading terminal can only show DU applications of the implementation class EE_TKA№EEEV, since there is no protection against access for them, and, optionally, applications of the implementation class EE_RT, respectively ΌΕ_ΑΌ, to which the trading terminal has read rights (owns key _{В ВУАРСР} ).

The order of viewing the remote control application:

1. The owner of the chip card inserts a remote control chip-card (chip card with a valid remote control container) into the terminal.

2. The service terminal checks for the presence of the remote control container using the following commands:

• FILE SELECTION: ZEEST ETIE <AGO _UAZ > (Error message if it is not possible to select a container).

• READING THE RECORD: BEAE HESO1Sh <SR1 from EE_Sh, 0> (reading the identifier of the remote control container).

Optionally, the terminal checks the validity of the remote control container. For this, the service terminal requires the internal identification of the remote control container using the command:

• INTERNAL IDENTIFICATION: ΙΝΊΈΗΝΑΕ AITNEKPUTATE <random number, KS from K _AiT >

The service terminal checks the response and stops the operation if the answer is incorrect (with an error message).

3. The service terminal provides the owner of the chip card with a choice of several additional options. One of them is called Viewing Remote Control Applications. The owner of the chip card selects it.

4. The service terminal confirms its right of access with the following commands:

• CALLING THE CASUAL CHIP CARD NUMBER: SET FORMER ^ E • EXTERNAL IDENTIFICATION: EXΊΈΗΝ.ΑΕ AITNEKPSATE <K _zo (random number), Kgo from K _zo >

5. For the DU applications of the implementation classes OE_RT and ΌΕ_ΑΌ, the contents of the elementary file EE_E1P of the directory are controlled by the sequential selection of one-by-one separate DU applications and, after confirming the right of external access with the key _K0 , the contents of the individual elementary files EE_UTO (or part in accordance with the regulatory framework B & B), as well as the elementary file EE_AJA. The following commands are used:

When 1 = 0, ..., pG | l _K - 1 use the command:

• READING THE RECORD: BEAE NESO1Sh <ZE1 of EE_Sh, 1>

The response message contains the application’s own identifier P1X _A , equal to 00 ... 00, if no application is loaded into the corresponding help file EE. As an alternative to the BEAE VESOVE command for reading a record from the elementary file EE_E1P of the catalog, in certain cases the search command ZEEK can also be used.

When P1X _{A is} not equal to 00 ... 00, use the commands:

• FILE SELECTION: ZEEST ETIE <P1X _a >

• READING THE RECORD: BEAE NESO1Sh <ZE1 of EE_UTO, 0>

• Display (possibly parts) of the response message • READING THE RECORD: BEAE NESO1Sh <ZE1 of EE_UAIE, 0>

• FILE SELECTION: ZEEST E1E <AYUAZ>

b. For the DU-applications of the implementation class EE_TACHER, the content (or parts thereof in accordance with the B & B standards) is read out of each record in EE_TKA№EEE with the following commands:

• FILE SELECTION: ZEEST E1E <ASHUAZ>

• If 1 = 0, ..., Swede-najazhek - 1 use the command:

• READING THE RECORD: NOT.A1) HESO1SH <ZE1 of EE_TVA№EEV, 1>

(The response message transmits the content having a serial number ί entries in EE_TKA№EEEV) • If the content is available, it is shown in an interpreted form (for example, the data has been read / the storage period has expired).

Viewing the implementation class OR_RT applications, respectively ΌΕ_ΑΌ, in relation to which the trading terminal has read permissions (which owns the key to _VUAZR) occurs as described herein, but with two differences: for confirmation of the right external instead of the access key for _Points, which is owned by only the system operator, use the key KVUAZR. If the trading terminal does not have a KSKAIT key generation key, but, nevertheless, would like to verify the validity of the remote control applications, then this trading terminal may require identification of at least one remote control application instead of internal identification. This verification is based, as already mentioned, on the knowledge of the corresponding key _KUAZR or _{KUAZR by the} chip card.

For DU-applications of the implementation class EE_TKA№EEE there is a sequential, as described above, enumeration of the content (or its parts according to the B & B norms) one after the other of each EE_TAGER entry.

Operation Interpretation of remote control applications is carried out as described above. For this purpose, the terminal provides the cardholder with a choice of an additional option Interpretation of remote applications. In addition to the information visually presented during the browsing operation, data from the elementary files EE_UTO and EE_UAlE that need to be interpreted by the provider (for example, data encoded from the outside) and data from the elementary file EP_UTEKMAY (for example, the number of miles earned in the past) can be presented years to receive discounts on the system Mjek & Mogue). The indicated operation is possible, however, only for those remote control applications for which the provider (at its sole discretion) will provide the corresponding keys on the terminal. To read the elementary file ЕР_ЮТЕКМЬ ДУapplications, the key К | _AAAZR (confirmation of the right of access from the outside). For outside-encoded data inside the elementary files ΕΡ_ΙΝΡΘ, ΕΡ_ΙΝΤΕΚΝ and EE \ EAEEE, as well as the memory for the transmitted data EE_TKA№EEK, the corresponding provider keys are required. The terminal program, based on its own identifier P1X of the selected remote application, can easily decide for which applications there are keys for interpreting the data.

Operation Transferring remote applications means transferring all or selected remote applications from the source chip card to the destination chip card at the service terminal. At the same time, it is necessary that there are no loaded remote control applications in the destination container of the destination chip card and that after the transfer all remote control applications from the original chip card are deleted. Both that, and another can be reached by consecutive application of operation Removal of the DU-application. In addition, the validity of the remote control chip cards must be verified, and the destination chip cards must have sufficient memory space. The application transfer operation itself is mainly based on the extension of the View Remote Application operation by additionally reading data from the elementary file ΕΕ_INΤΕΚNΑ ^ and keys 1 <| _AAAZR and K _{| A. AAZR} and repeated use of the operation Download the remote control application.

Together with the remote control data, the identifier (GO) of the remote control is transferred to the destination chip so that the remote control applications behave in the destination chip in exactly the same way as in the original chip. The reason for this decision is that the provider-generated derivatives of the keys based on the identifier (GO) of the remote control do not change when copying. In addition, the provider does not want to change the accounting in the background system, since it usually identifies remote control chip cards by remote control containers. It is imperative to ensure that when transmitting the identifier (GO) of the remote control container, this number that is uniquely determined throughout the system will be deleted from the original chip card.

In order to be able to read, in particular, the elementary file EP_UTE ^ AB and the keys 1 <| _A -. _АЗР and К _{| А} , _ААЗР , the service terminal after checking the right of access from the outside with the key К _Зо (similarly to the operation Uninstall the remote application) first overwrites the keys К | _А - _АЗР , due to which it can, after re-checking the right of access with the key K ^ _АЗР, send data from the elementary file ЕР_ЮТЕ: ^ АЬ.

In addition to the remote control applications of the implementation classes ΌΕ_ΡΤ and OP_AO, you must send the file EE_TKA№EEK. To do this, one by one, objects of this class that are not marked as deleted or as objects with an expired storage period are subsequently deleted one after another, their signature is checked with the key К _ЗУ ^ _АЗС and the destination chip cards are transferred to the file ЕЕ_ТКА№ЕЕК. However, in the destination chip card, these objects are marked as not taken so that they continue to be valid.

In conclusion, it is still necessary to transmit the global data of the remote control container. In particular, the counter of serial numbers of the destination chip card should be set to the value of the original chip card.

The following describes how to enter remote control data.

There are three possible cases of entering remote control data at the trading terminal, depending on the type of remote control application.

Initially, data acquisition will be considered in the case of implementation classes ΌΕ_ΡΤ or OP_AO.

The provider needs to write data to the DU Appendix A implementation class ΌΕ_ΡΤ or ОР_АО.

The procedure for entering remote control data:

1. The owner of the chip card inserts the remote control chip card into the trading terminal.

2. The trading terminal checks for the presence of a remote control container using the following commands:

• FILE SELECTION: ZEESLES ILYE <AGO ^ _Z > (Error message if it is not possible to select a container).

• READING THE RECORD: ЕЕА1) ИЕССЖ1) <ЗЕ1 from ЕЕ_ГО, 0> (reading the identifier (GO) of the DU-container).

3. Validation of the DUcontainer. If the trading terminal itself does not have the key generation key KSK _Ait , it may require the remote control container internal identification:

• INTERNAL IDENTIFICATION: 1UTEIUA AITNEKPShSATE <random number, KGO from K _Ait >

A trading terminal (which does not have a KKK _Ait key generation key) can indirectly verify the validity of the remote control container by checking the validity of remote control A. The fact is that the remote control application could only be downloaded on the service terminal, which checked the validity of the remote control during the download process. Verification of the validity of the DU application A can be reduced to checking by the trading terminal whether the DU container has the key К _ЬУА8Р or К | <\ - _А8Р for the DU application A. The trading terminal can verify this, for example, using the commands:

• FILE SELECTION: 8EBEST FULL <P1X _A > (Error message if the remote control application A is not loaded into the remote control container).

• INTERNAL IDENTIFICATION: 1ХТЕХАЕ АиТНЕЫТ1У1САТЕ <random number, KGO from К _Е уа8р or К _Е уа8р>

The trading terminal checks the response and stops the operation if the answer is incorrect (with an error message).

4. The trading terminal selects DU Appendix A, identifies itself and describes the elementary files necessary for conducting the transaction using the following commands:

• Select files: 8EBEST YE <R1H _A> (if the team has already been made in step 3 of the program, do not use it) • Challenge random number smart card: GEt SNAEEEHSE • External identification: EHTEKHA AITNEHT1SATE <To _UA8R (random number), CLC of TO _LUA8P >

• Optional: RECORD UPDATE: υΡΌАТЕ КЕСОКБ <8Е1 of the file ЕР_ _1ХЕО from the file (directory) ΌΓ_Χ, data>

• Optional: RECORD UPDATE: IREATE KESOKB <8E1 file

EE_1XTEK.XAE from the file (directory) ΌΓ_Χ, data>

• Optional: RECORD UPDATE: ЕОАТЕ КЕСОББ <8Е1 of the file ЕЕ Х’АЕЕ'Е from the file (directory) ΌΓ_Χ, data>

The following case is the acquisition of data in the implementation class EE_TKAX8EEK.

Specifically, for remote control applications of the EE_TRAX8EEP implementation class (Talon application class), the provider does not need to occupy any own file structure ΌΓ_Χ for its application. Thanks to this decision, the owner of the chip card should not go to the service terminal to download the remote application before using the Talon remote application. Instead, he can directly purchase a ticket or receipt directly at the trading terminal and receive compensation for them on another terminal (using the fetch operation), or simply just present this ticket, respectively, the receipt (using the read operation). Thus, as a result of entering DUdata in an implicit form, loading of DU-applications of the implementation class occurs

EE_TKAKH8EEK. For this class of applications, there is an implementation class EE_TKAX8EEK consisting of separate objects that have the form of records. Data entry in EE_TKAH8EEK is possible exclusively with the help of the TKAH8EEK data transfer command. For this, the trading terminal must have a valid redemption key K _EEC and have its own identifier P1X _{A of the} remote control application A.

The procedure for entering remote control data:

1. The owner of the chip card inserts the remote control chip card into the trading terminal.

2. The trading terminal checks for the presence of a remote control container using the following commands:

• FILE SELECTION: 8EBEST Р1ЬЕ <АГОν _Α8 > (Error message if it is not possible to select a container).

• READING THE RECORD: KEAE KESOKO <8E1 from EE_GO, 0> (reading the number of the DUcontainer).

3. The trading terminal reads the serial number, which is additionally included in the message identification code (MAC) from step 4 of the program:

• READING THE RECORD: KEA1) KESOKE <8E1 from EE_8EO, 0> (reading the serial number).

4. The data transfer command TKAX8EEK in the elementary file EE_TKAX8EEK record:

• DATA TRANSFER: TKAKH8EEK <transaction date, expiration date, shaper code, data, application’s own identifier (P1X _A ), message identification code (MAC) with the key _EEC >

5. By checking the response message of the TKAX8EEK data transfer command, the trading terminal can verify the validity of the remote control container (does it own the joint secret of the K _EEC key). On this subject, see the above description of the response message of the TKAX8EEK command.

In conclusion about the operation of acquiring remote control data through the redemption operation.

The provider can use the Redemption operation with the TKAX8EEK data transfer command to generate a right (in the form, for example, of a coupon or receipt) in the data transfer field of the EE-TKAX8EEK elementary file, which can be used by another provider in the future. The data from the elementary file ЕЕ ^ АиЕ, respectively ЕЕ_1ХЕО ДУ-application A of the repayment provider is redeemed. The owner of the chip card receives this right in the form of an object in the elementary file (implementation class) EE_TKAX8EEK.

The procedure for entering remote control data:

1. The owner of the chip card inserts the remote control chip card into the trading terminal.

2. The trading terminal checks for the presence of a remote control container using the following commands:

• FILE SELECTION: 8EBEST G1E <AGO _νΑ8 > (error message if it is not possible to select a container).

• READING THE RECORD: ΚΕΑΌ ΚΕίΌΚΙ) <8ΕΙ from ΕΕ_ΙΌ, 0> (reading the identifier of the remote control).

3. The trading terminal reads the serial number with the message identification code (MAC) additionally included in it from step 4 of the program:

• READING THE RECORD: ΚΕΑΌ ΚΕίΌΚΙ) <8ΡΙ from ΕΕ_8Ερ. 0> (reading the serial number of the remote control container).

4. The trading terminal selects Application A:

• FILE SELECTION: 8ΕΕΕ (Ί 'ΕΙΕΕ <Р1Х _А > (Error message if the remote control application A is not loaded into the remote control container).

5. The trading terminal uses the data transfer command ΤΚΑΝ8ΕΕΚ to redeem the data from the file ΕΕ_νΑΕυΕ, respectively, from the file ΕΕ_ΙΝΕΟ:

• DATA TRANSFER: ΤΚΑΝ8ΕΕΚ <data, message identification code (MAC) with the key Κ _{ϋΕ (3} >

The composition of the command message of the data transmission command ΤΚΑΝ8ΕΕΚ has already been described above. The terminal gains the right to a redemption operation when it can, using the Kd ^ key, generate the correct signature from the data that is checked by the DU container. In the positive case, the remote control container creates an entry in the elementary file of the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ and increases the serial number by one unit.

6. By checking the response message of the data transfer command ΤΚΑΝ8ΕΕΚ, the trading terminal can verify the validity of the remote control container (does it own the joint secret of the key K _in , _C ).

And finally, it is necessary to describe another way of extinguishing remote control data. There are two types of repayment transactions.

First, the data of the remote control applications of the implementation class ΌΕ_ΡΤ or ΌΕ_ΑΌ can be canceled by the corresponding provider using the Redemption operation, i.e. by acquiring remote control data through redemption. As a result, one value (value) is used and a potential right arises for the next value (value).

Secondly, the data can be taken once from the elementary file of the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ using the auxiliary fetch command ΤΑΚΕ. In this case, the right is considered used, the data remains for their possible further use (for example, a ticket after compensation for the fare is still needed for the return trip) in the data transfer field marked as read until they are overwritten, if necessary, by other objects.

The procedure for redeeming remote control data by fetch command ΤΑΚΕ:

1. The owner of the chip card inserts the remote control chip card into the trading terminal.

2. The trading terminal checks for the presence of a remote control container using the following commands:

• FILE SELECTION: 8ΕΕΕ (Ί 'ΕΙΕΕ <ΑΙΌ _νΑ3 > (Error message if it is not possible to select a container).

• READING THE RECORD: ΚΕΑΌ ΚΕίΌΚΙ) <8ΕΙ from ΕΕ_ΙΌ, 0> (reading the identifier of the remote control).

3. First, the trading terminal, using a special version of the operation View Remote Control Data, reads the available objects from the elementary file of the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ in order to determine the presence of the desired object. Alternatively, you can search using the search command 8ΕΕΚ in a specific combination. If successful, the terminal determines the number ί of the desired record.

4. The terminal marks the record with the number ί as deleted, passing the number ί, a random number calculated by it, its own identifier (ΡΙΧ) for the application and the identifier (GO) of the terminal with the selection command ΤΑΚΕ:

• SAMPLE: ΤΑΚΕ <ί, random number, ΡΙΧ, terminal GO®

The trading terminal uses the fetch command ΤΑΚΕ to read data from the elementary file of the implementation class ΕΕ_ΤΚΑΝ8ΕΕΚ, while marking this data with the fetch code. The execution of this command additionally leads to the formation of two different cryptograms C ₁ and C ₂ .

The D1container calculates the cryptogram C1 using the key Κ _3ΙΟ _ _{νΑ3 (Α} Using it, a user presenting an object taken with the mark C ₁ can receive confirmation from the system operator of its validity and the one-time transmission thereof. The validity and one-time transaction is determined based on the provider's cryptogram, from which emanates the active sites (and which has been verified by the chip card, cm. description data transfer command ΤΚΑΝ8ΕΕΚ.) and counter readings transaction sequence numbers and the cryptogram C ₁ calculates th chip card with the sample.

The C2 cryptogram is calculated by the DUcontainer using the Cddz derivative key obtained on the basis of the key generation key ключей _{ϋΕ (3} , the application’s own identifier (ΡΙΧ) and the identifier (GO) of the terminal. Knowing the joint secret of the Cd ^ key, the DU container can directly confirm the validity of the terminal Since, when executing the data transfer command ΤΚΑΝ8ΕΕΚ, it is also checked that only valid coupons or receipts are entered into the memory of the valid DU container, based on this information, you can conclude that the cryptogram C _{2 is} indirectly generated based on the serial number, bit / bit of the sample code and identifier (GO) of the remote control container, the remote control container can even confirm to the terminal that the object is sampled once.

Everyone has the right to select using the fetch command.

In addition, the service terminal provides the ability to deactivate, respectively activate using a password or PIN protection for reading remote control applications of the implementation classes ΌΡ_ΡΤ and ΌΡ_ΑΌ. In addition, the owner of the chip card can, knowing the password or PIN code, change it, and the system operator can return it to its original state, using the key K _{3o to} confirm the right to external access. Non-digital characters or chains of characters of arbitrary length can be used as a PIN code or password.

Claims (34)

CLAIM 1. A chip card used to conduct transactions in which units of cash value or other non-financial claims / rights expressing digital data are transferred between the owner of the chip card and at least one transaction partner (provider) or presented to the provider for credentials of these requirements / rights, and the chip card has a memory that stores the data necessary for conducting these transactions, characterized by the presence of the following means: - devices for loading into the chip card one or more chip card applications (DU applications) corresponding in each case to a particular provider, each of which allows transactions between the owner of the chip card and the provider to which this application is allocated, - which is not the provider’s own area of memory for the transferred data (ЕР_ТКАЛ3РЕК), designed to accommodate exchanged or presented during transactions between different data providers representing units of monetary value or non-financial claims / rights, and - devices for recording data into memory for data being transferred in response to a data recording / transmission command (TKALZREK). 2. The chip card according to claim 1, in which the device for loading has the following components: data structure stored inside (help file ΌΡ_νΑ3, remote control container), which includes: - a substructure (help file OP_RT, help file ΌΡ_ΑΌ, remote control application) into which data (remote control data) can be loaded, which is necessary to enable transactions between the owner of the chip card and the provider; - a record of the data description containing information about the type and / or structure of the data stored in the sub-structure (DU-application), and this record also has in its composition: - a code (identifier (GO) of the container) identifying the data structure (DUcontainer) and / or the chip card, and - at least one system key (KBO) that protects the integrity of the data description record and / or data structure (DUcontainer) from modifications. 3. The chip card according to any one of paragraphs.1 or 2, characterized in that it, in addition, has at least one of the following distinctive features: - a device for loading the data necessary for conducting transactions into a substructure using at least one system key; - a device for entering data into a data description record in order to reconcile the data of this record with the data loaded into the substructure; - a device for forming in the memory of the chip card another substructure into which the data necessary for the transaction can be loaded, and / or - a device for dynamic memory management in a chip card. 4. A chip card according to any one of the preceding paragraphs, characterized in that: in the case of substructures (DU applications) we are talking about independent substructures allocated in each case to one specific provider, the data description record is protected from modifications by at least one system key (K _3o ) and can only be changed using this key , and the fact that loading substructures (remote control applications) can only be done using the system key data description in the record. 5. A chip card according to any one of the preceding paragraphs, further characterized in that the data description record has at least one of the following distinguishing features: - at least one identification key (K A _&T ) for checking the access rights of the chip card with respect to the terminal and / or for checking the access rights of the terminal with respect to the chip card; - at least one marking key (К _{3Ю νΑ3 (4} for marking data taken from memory for data being transferred; - a key generation key (KOK _CEC ) for generating specific keys for terminals and applications designed to check the right to write data to memory for data being transferred and / or to cancel digital data; - personal identification number (PIN) for verification by the chip card holder of the right to a transaction; and in that the system key (K _DA) identifying key (K _AIT), marking key (K _SiO ^ _AZS) and the key forming keys (COCs _CEC) are individual keys chip card or specific key data structures (BU ^ TT ), and the fact that the substructure (DU-application) has at least one of the following distinguishing features: - at least one memory partition (EE ^ ASHE) for storing digital data; - at least one memory partition (EE_ShTE ^ AB) for storing internal data on a substructure; - at least one memory partition (EE_UTO) for storing informational, non-internal data on a substructure; - a memory section (ΕΕ_ΚΕΥ) for storing keys of at least one key (К ^ _АЗР , К _СТАЗР ) protecting the processes of writing data to the section and / or reading data from the memory section for digital data, and / or the memory section for internal data, and / or memory partition for information data, and the fact that the chip card further includes: - a device for writing data to a section and / or reading data from a memory section for digital data, a memory section for internal data and a memory section for information data, and the fact that the download device includes: - a device for recording keys in a memory section for storing keys under the protection of at least one system key. 6. A chip card according to any one of the preceding paragraphs, characterized in that the substructure has at least one of the following distinguishing features: - a key (К ^ _АЗР ) for checking the right to write data to the substructure; - a key (К ^ _АЗР ) for checking the right to read data from a substructure. 7. The chip card according to any one of the preceding paragraphs, characterized in that the memory section for storing keys stores its own specific key for each substructure, and in that at least one substructure (DU application) enables transactions through at least , one of the specific keys (К | _Л - _АЗР . К _ИА8Р ), each of which is specific to the corresponding substructure (DU-applications) and does not depend on the keys of other substructures (DU-applications). 8. The chip card according to any one of the preceding paragraphs, characterized in that this chip card has several substructures (remote control applications) that serve, respectively, for transactions between certain providers and the owner of the chip card, and that the transaction includes recording data in the field, and / or reading data from the data transmission field, and / or writing data to the section, and / or reading data from the memory section for digital data. 9. The chip card according to any one of the preceding paragraphs, characterized in that it also includes: a device for conducting transactions both between separate substructures (DU-applications), and between one substructure and one provider. 10. A chip card according to any one of the preceding paragraphs, characterized in that: - the system key ( _KZ ) is known only to the owner of the system (system operator, CO) and is the individual key of the chip card and / or the specific key of the data structure (remote control container), and the fact that other keys are contained in the data description record, are individual keys of the chip card and / or specific keys of the data structure (DUcontainer). 11. A chip card according to any one of the preceding paragraphs, characterized in that the data description record has one or more of the following distinctive features: - identification number (EE_1B) specifying the data structure; - a catalog of the substructures contained in the data structure (EE_B1P), while the specified catalog contains specific identification numbers of the substructures (DU applications) loaded into the data structure (DU container), as well as information about that part of the data structure (DU container) in which these substructures are stored (remote control applications); - The version number of the data structure (EE_USER). 12. The chip card according to any one of the preceding paragraphs, characterized by the presence of at least one of the following distinctive features: - a device for conducting the sampling process (Take), which provides for the selection and cancellation of the data contained in the memory for the transmitted data; - a device for generating one or more evidence of data during sampling, respectively, when paying off the data contained in the memory for the data being transferred. 13. A chip card according to any one of the preceding paragraphs, characterized in that said chip card for forming distinctive signs of its validity has the following means: - the marking key K uazs _{occupies 8} to form a digital signature on the data taken; - a device for generating a transaction identifying transaction number, also used to generate a digital signature. 14. The chip card according to any one of the preceding paragraphs, characterized in that the marking key K _{8YU νΑ8 (3} is a secret key obtained as a derivative of a secret key for generating keys, and providers use public keys to verify the signature. 15. A chip card according to any one of the preceding paragraphs, characterized in that it has at least one of the following distinguishing features: - a device for generating specific terminals and substructures keys (K _EEC) with a key for generating keys (K6K _CEC); - a device for verifying the legitimacy and / or protection of a transaction using at least one of the following distinguishing features: a specific key of the terminal and substructure (K _C ec), at least one identifying key (K _Ait ), at least one system key (K ₃ o), at least one specific key of the substructure (Kwazr, K ^ uazr ), a marking key (K _31O _ _UA 8 _S ), personal identification number (PIN), substructure code, terminal code. 16. The chip card according to any one of the preceding paragraphs, characterized in that it, in addition, has at least one of the following distinctive features: - a device for identifying access rights and / or terminal using an identification key before starting the process of reading or writing data, - a device for carrying out processes of reading or writing data protected by digital signature and / or encrypted. 17. The chip card according to any one of the preceding paragraphs, characterized in that it, in addition, has at least one of the following distinctive features: - a device for activating and deactivating protection using a PIN, - a device for changing PINs. 18. The chip card according to any one of the preceding paragraphs, characterized in that the data structure according to any of the preceding paragraphs does not depend on the platform of the chip card, and the chip card itself includes, in addition, a device for transferring the data structure or parts of the data structure to another chip card. 19. Chip card, characterized by the presence of the following means: a provider’s own memory area for writing data to or reading data from this area by various providers with the aim of transmitting digital data expressing monetary value units and / or other non-financial claims / rights between various providers. 20. The terminal for use with a chip card according to any one of claims 1 to 19, characterized in that the terminal includes: - a device for identifying the data structure (remote container) of the chip card, as well as identifying the code identifying the data structure (container identifier (GO)); and the fact that he, in addition, has at least one of the following distinguishing features: - a device for reading data from at least one of the substructures and / or from the data description record and / or from the memory for the transmitted chip card data; - a device for recording data in memory for the transferred data of the chip card; - a device for loading the data necessary for conducting transactions into at least one of the substructures (remote control applications) of the chip card. 21. The terminal according to claim 20, characterized in that he, in addition, has at least one of the following distinctive features: - a device for conducting transactions between the provider and the owner of the chip card, and the transaction includes at least one of the following stages: - writing data to a memory section for digital data, - writing data to memory for data being transferred, - selection and / or cancellation of data from memory for the transmitted data, - reading data from a substructure, - reading data from memory for data being transferred. 22. The terminal according to any one of paragraphs.20 or 21, further characterized in that it includes: - a device for verifying the legitimacy and / or protection of a transaction using at least one of the following distinguishing features: - a specific key (To _its ) terminal and substructure, - at least one chip card-specific or data-structure-specific (ΌΤ_νΑ8) identifier key); - at least one individual for the chip card or specific for the data structure (EE_UA8) system key (K ₈₀ ), - at least one specific key (To _b ya8r, Kkuazr) substructures, - a marking key, individual for the chip card or specific for the data structure (EE_UA8) (To _{zy UAZS} ), - individual for the chip card or specific for the data structure (EE_UA8) personal identification number (PIN), - application-specific substructure code, - specific terminal code. 23. The terminal according to any one of paragraphs.20-22, characterized in that the device for recording data into memory for data being transmitted has the following means: - a device for encoding data using a specific key (K _CEC ) of the terminal and substructure to confirm the right to write data. 24. The terminal according to any one of paragraphs.20-23, characterized in that it includes, in addition, a device for performing a data retrieval operation from the memory for the data being transferred, with the help of which the data contained in this memory are sampled and / or canceled. 25. The terminal according to any one of paragraphs.20-24, further characterized in that it has at least one of the following distinctive features: - a device that marks in memory for the transmitted data the read data, - a device that marks expired data in memory for transmitted data. 26. The terminal according to any one of paragraphs.20-25, characterized in that the device for conducting transactions has at least one of the following distinctive features: - a device for changing digital data in a substructure; - a device for conducting transactions between different providers (communication services) at the expense of, respectively, in favor of the owner of the chip card. 27. The terminal according to any one of paragraphs.20-26, characterized in that it also includes: - a device for identifying access rights of a terminal with respect to a chip card and / or a chip card with respect to a terminal using at least one identifying key; - a device to protect the transaction by the owner of the chip card using a personal identification number (PIN), - a device for activating and deactivating protection using a personal identification number (PIN). 28. The terminal according to any one of paragraphs.20-27, further characterized in that it has at least one of the following distinctive features: - a device for transmitting a specific terminal code to the chip card; - a device for transferring a code specifying a substructure to a chip card; - an access right identification device using a specific terminal key and substructure, as well as a specific terminal and substructure code, - a device for conducting read or write operations protected by digital signature and / or encoding. 29. The terminal according to any one of paragraphs.20-28, further characterized in that it has at least one of the following distinctive features: - a device for selecting a substructure (remote control application); - a device for viewing the substructure at the terminal; - a device for viewing substructure data at the terminal; - a device for loading a substructure (remote control application) into a chip card; - a device for downloading the code of the loaded substructure (remote control application) to the chip card; - a device for removing a substructure from a chip card; - a device for replacing one substructure with another substructure; - a device for transferring a substructure to another chip card; - a device for interpreting a substructure in relation to its function and the provider allocated to it, as well as for reading and viewing the information stored in it. 30. A method of conducting transactions between the owner of a chip card and at least one provider using a chip card, as well as a terminal, comprising one of the following stages: - creation of a data structure stored in the chip card into which the data of the chip card application allocated to the provider (remote control data) can be loaded, necessary to enable transactions between the chip card holder and the provider, as well as - writing data to the structure or reading data from the data structure (Remote Application) for transactions between the provider and the owner of the chip card, - the creation of a non-proprietary memory area for the transmitted data (EE_TKA№EEEV) intended to accommodate exchanged or presented during transactions between various data providers representing units of monetary value or non-financial claims / rights, as well as - writing data to the memory for the data being transferred or reading data from the memory for the data being transferred. 31. The method according to p. 30, characterized in that the said method includes at least one of the following stages: - the use of a chip card according to any one of claims 1-19; - use of the terminal according to any one of paragraphs.20-29; - writing data to a memory section or reading data from a memory section for digital data, or a memory section for internal data, or a memory section for information data of at least one of the substructures (remote control applications). 32. The method according to p. 30 or 31, further characterized in that it comprises at least one of the following stages: - identification of access rights of the terminal and / or chip card using at least one key; - Transaction protection by using digital signature and / or encoding using at least one key. 33. A method of loading data into a chip card using a terminal, characterized in that said method comprises at least one of the following steps: - loading data into the substructure (DU application) of the chip card; - entering data into the data description record of the chip card, and this method includes at least one of the following stages: - the use of a chip card according to any one of paragraphs.1-19 and - use of the terminal according to any one of paragraphs.20-29. 34. A system for conducting transactions, characterized by the presence of the following funds: - a chip card according to any one of claims 1 to 19 and - terminal according to any one of paragraphs.20-29.