BG63233B1 - Chipcard and method for its application - Google Patents

Abstract

The chipcard is designed for making deals where the currency (value) information (data) representing funds or other non money-related rights (assets) is exchanged between the owner of the card and at least one partner in the deal (who makes the service) or is submitted to the person making the service for ckecking the same rights (assets). The chipcard has a memory in which the necessary information (data) for materializing the deal is stored and for this reason a device for charging the card with one or more requests from the card (VAS requests) is provided intended to allow the materialization of the deals between the card owner and one or more service performers. 34 claims, 10 figures

Description

(54) CHIPCARD AND METHOD OF USE

Technical field

The invention relates to a chip card, a chip card terminal and method for using the chip card, and a chip card system.

BACKGROUND OF THE INVENTION

Microprocessor-based chip cards having a payment function (ie payment), ie electronic wallet, cash, credit function, etc., are in the process of being implemented and depending on their nature, preconditions are set by organizations such as ZKA (Zentraler Kreditausschuss), VISA, or EMV (Europav Mastercard VISA) so that they can be used as a means of payment (money-exchange) as indicated in the following literature sources:

ZKA, Zentraler Kreditausschuss, “interaction specification for ec-card with chip”, 10/27/1995;

Europay International, “Integrated Circuit Card, Payment Systems Specification, EMV'96”, V3.0, 30-Jun-1996;

ISO / IEC 7816-4, 'Information technology

- Identification cards - Integrated circuit (s) cards with contacts, Part 4: Interindustry commands for interchange ”, 01-09-1995;

prEN 1546-1, “Identification card systems

- Inter-sector electronic purse, Part 1: Definitions, concepts and structures ”. 15.03.1995;

prEN 1546-2, “Identification card systems

- Inter-sector electronic purse, Part 2: Securin 'architecture, 03.07.1995;

prEN 1546-3, “Identification card systems

- Inter-sector electronic purse, Part 3: Data elements and interchanges ”, 09.12.1994.

An up-to-date overview of chip cards can be found in Lit.

Stefan Schutt, Bert Kohlgraf: “Chipkarten, Technische Merkmale, Normung, Einsatzgebiete”, (“Chip cards, Technical Characteristics, Standards, Fields of Employment”), R. Oldenbourg Verlag, Munich / Vienna, 1996, ISBN 3-486-23738 -1.

Traditional chip cards are usually used only for individual purposes, for example as electronic money or as electronic identification (identification) means. Of course, the requests (requests) embedded in these chip cards are simple5 but are constant, ie. they are embedded during the production (creation) of the chip card and are stored throughout the life of the card.

Traditional chip cards are limited to 10 on two sides - in terms of their variability as well as in their functionality. Especially traditional chip cards are fixed in accordance with the process of their preparation with regard to their functionality and 15 may not change for a long time.

SUMMARY OF THE INVENTION

According to the object of the present invention, a chip card is used, the functionality of which is variable.

A further object of the invention is the use of a chip card, for which the number and nature of the requests presented by the chip card, or the requests and transactions, can be quite variable, even after the manufacturing process (the process of its preparation). It might be possible to load (write) additional requests in these chip cards, it would be possible to delete (delete) the requests from the chip card and it is possible for individual requests to be found independently of one another in the data and technological protections and to act independently of one another. the other.

The chip card must, for example, be implemented with data and technological secret conditions (protections) according to ISO 7816: the individual applications of the card must, of course, be independent, especially from the card itself.

It is a further object of the invention to provide a chip card by which the user himself can define (limit) or combine or change the number or nature of the requests available on his card.

It is a further object of the invention to provide a chip card with means to which internal services (i.e., closed, inaccessible internal connection for requests, in the sense of unauthorized purchases or service transfers (exchanges), obliging external partners to take participation), as well as mutual services (ie requests with additional external connections involving external partners) are eligible and can be fulfilled.

According to one aspect of the invention, the device is implemented with means from which one or more card requests can be entered into the card, through which any transaction between the cardholder and one or more service providers is possible.

Through such input (loading) the chip card is configured so that it is created with new functionality, ie. may execute a request that was not previously allowed to it. The information (data) entered leads to the definition of requests and their execution together with the basic functions of the card, for example the operating system, which were not previously realized on the card. As a result, the functionality of the card has been expanded with such a request entry through this particular application.

In accordance with the invention, an information structure (DF_VAS) is implemented on the chip card according to the invention, which is subsequently subdivided into separate structures and a definitive information network, the information structure is specifically identified by its code identification means and is also independent of the card on the card . The so-called requests can be reintroduced into a separate structure, ie the features or requests of the chip card. As a result, it is possible to enter into a transaction between the cardholder and the service provider specific to that request by entering a separate request from the chip card. The defined information network inside the information structure contains data relating to the nature and / or content of the requests entered into the special structure. However, at least one structure of the defined information network, preferably the entire information structure, is protected by the means of at least one system key against modifications and can only be modified by using that key. Instead of a system key, another security mechanism, or security means, can also be achieved by a means for which protection against modifications can be accomplished, for example, through a personal identification number (PIN) or another means that performs the same protection.

With this structure it is possible to enter multiple requests into the special structure and also delete (delete) them one more time from the special structure, by which the card becomes variable in terms of its functions or requests, which can then be done .

Entry and deletion (deletion) of requests is accomplished by recording specific information about the request and keys in the realized special structure. Through the protection of the system key and the encoding of the information structure, the information structure, having acquired multifunctionality, has become independent of the card on the card, for example, and also has a supporting respect for its protected architecture and independence of the card board.

Depending on the requests entered in the special structure, it is then possible to transact through the funds of the card transactions between the cardholder and the service provider, which are dependent on the entered requests.

It is preferable, further, that the chip card contains an exchange area in which the information exchanged during the execution of the transactions can be recorded or readable. For the same reasons, terminal specific keys have been created for reading exchange information, and individual accesses are presented independently from a security (security) point of view.

The individual special structures or requests for realization on the card are preferably interdependent and each is assigned to a special service provider. They are, so to speak, information to execute a specific request, own rights or specific to that requestor. According to the type of request and tailored to the service provider, they contain different information about it, for example data representing specific values (bonus points, calculated balance, etc.), requesting data representing the service provider. etc. Of course, it is preferable, of course, that they contain keys that are specific to the request, through which the access to the data of the specific structure is made possible in a way whose technical protection is independent of other special structures. The introduction or creation of special structures or the request itself, on the other hand, is protected by at least one badly needed system key.

Preferably, prior to the execution of a transaction, it is mutually established between the chip card and the terminal, and on request, respectively, the specific authentication key of the individual structure created for this purpose.

It may be that when the transactions are completed, the information, then, may be stored in a special structure reserved for special VAS requests or read from there, or transactions may be effected by changing the storage area for exchange. First, the specific query keys are used. In the latter case, a specific request key is used, and above all, also a terminal specific key, which, for example, is realized by means of creating a key executed in the card and by the specific request information. The information is stored in such a way in the data exchange memory that it can be downloaded by the requester through the terminal, which mainly participates by marking 35, when the stored information in the data exchange memory is invalid. If this involves a service provider that has not been specifically enrolled for the operation, it confuses the implementation of the so-called mutual services, ie. cash data is exchanged between different service providers for or at the expense of the cardholder.

In addition, for added security, 45 a PIN or password was used to confirm the right to perform an exchange procedure.

The variable structure of the card allows multiple requests, such as multiple numbers, to be placed on the card at different times.

The authenticity of downloaded information from the exchange memory is first and foremost protected by the use of a signature key or by using a digital signature or 5 at least only on a key. Of course, there is a special advantage in this context if the downloaded information still exists in the memory and the data is only deleted after being downloaded through the card. In this way, on the other hand, it is possible to obtain information containing the presentation of the transaction only after the transaction has been completed. In this way, and through a data retrieval tool, it is proven15 that the transaction has been completed only once.

There is, moreover, a particular advantage when the information (data) stored in the exchange memory is encoded 20 with deleted (missing) data, after which it loses its value. This makes it possible to execute requests that, for example, confuse the implementation of possible access valid only for a specific period.

By means of the transaction counter, which is also realized, the transaction data, respectively. monetary data with the relevant related transaction can be positively separated and identified.

As a general advantage, the chip card according to the invention further comprises a hierarchical information structure which is individually protected by means of various keys against modifications and which, at the level of the requests, in terms of the protected request in the information database, is variable, as each an individual request is protected about the rest by its own specific key and is independent of the rest, and the common structure is protected by at least one key system and a key identifier fitting the structure and is independent of the card board itself. The exchange memory structure allows for the exchange of data between the cardholder and the service provider, as well as between different service providers. Also, reading from and writing to the exchange memory is protected by keys, this also affects the card and the specific request, as well as additionally the specific terminal. Established prior authentication of each transaction, as well as, optionally, a PIN or password, further increase the security of the chip card according to the invention.

Claims 21 to 30 define a terminal for use with the chip card according to the invention. This terminal is used to enter or execute requests, to execute transactions, to view information, and to perform subsequent actions related to relevant requests and transactions. The transaction process between the cardholder and the service provider is defined in claims 31 to 33, the entry (loading) of information into the chip card according to the invention is defined in claims 34 and 35, and claim 36 defines a common system comprising the chip card and a terminal .

Explanation of the annexed figures

The invention is further explained by a preferred embodiment with an explanation of the accompanying drawings, of which:

Figure 1 is a graphical representation of the chip card according to the invention;

Figure 2 is a structural representation of the general system of the components of the invention;

Figure 3 - data flow throughout the system;

Figure 4 - possible groups of orders and operations by transaction model in schematic illustration;

Figure 5 is a schematic illustration of the security architecture of the chip card according to the invention;

Figure 6 is an information structure of the main VAS carrier implementation group;

Figure 7 is an embodiment of groups for performing the VAS carrier according to the exemplary action of the invention;

8 is an information structure of a VAS carrier according to the exemplary action of the invention;

Figure 9 is a schematic view of the information structure of the implementation group DF_PT;

Figure 10 is a schematic view of the information structure of the implementation group DF_AD.

Examples of carrying out the invention

The definitions of the terms used are as follows:

VAS: foreign exchange (payment) computer services;

VAS card: The VAS card is a chip card, with the means of which it is possible to perform payment computer services. The VAS card contains, among other requests, such as payment requests (ie, electronic portfolios), a VAS medium;

VAS media: The VAS media also contains information structure, access conditions, keys and computer commands for the administration (management and processing) of VAS requests and for accessing the functioning of VAS requests;

VAS request: VAS requests contain your VAS data. Access to VAS data is controlled through your VAS request. A VAS service provider processes one or more VAS requests in the VAS media. The use of a VAS request is defined by the request, reading and operating the VAS data. Your request may refer to both an internal and a mutual (external) service.

VAS service provider: The VAS service provider is responsible for its VAS request, which it processes in accordance with the basic (basic) conditions of the system operator and in accordance with its personal freedom of action, and only then provides access to using the cardholder through the system operator and the terminals. VAS requests must be entered (loaded) into the VAS media of the VAS card before its participation (use) in this respect is possible.

Internal service: An internal service is a type of VAS request used under the exclusive management of a respective VAS service provider. Internal service requests are closed-loop requests, which means that there is no calculation and execution of transactions involving external partners. Your request can be either an internal or a reciprocal service.

Mutual services: Requests for reciprocal (external) services are requests for internal services that are linked to external partners through additional (computer) external links.

//

I

Your request can be either an internal or an external service by nature.

SO, system operator: The system operator offers VAS service providers and VAS card holders to use them.

Outlet: The outlet or card slot takes VAS cards including VAS media into circulation (use /

CH, Card Holder: The card holder or card holder is a person who owns and uses the card (in this case: your VAS card) for possible participation in payment computer services. This person is not necessarily the real owner of the card.

Service terminal: The service terminal is the system operator's station for VAS requests. From the service terminal, the card holder can administer (process) your VAS requests to your VAS card (entering, viewing, displaying and exchanging VAS requests).

Dealer terminal (commercial, for transactions): The dealer terminal has payment functions and additionally offers VAS functions. This happens when the cardholder arranges for his / her VAS card, on the one hand, to make payments and, on the other, to participate in the benefit of the VAS.

AID request query): AID is a query name of no more than 16 bytes to accurately differentiate queries and select queries side by side without knowing the map information structure. The AID contains a Registered Request ID (RID) Contractor, with a length of 5 bytes, and an optional Own Identification Request Registrar (PIX), no longer than 11 bytes.

DF: ISO 7816 directory file.

EF: Elemental file according to ISO 7816.

Valid VAS medium: A VAS medium that has the ability to authenticate itself to the outside world.

KID (Key Identifier): A set of keys in the Elemental File containing the keys.

R&R: Rights and rules.

p: The maximum number of tasks in the DF PT implementation group.

a: The maximum number of tasks in the DF_AD execution group.

pshk: The maximum total number of tasks, pshsh = p + a

The number of entries in EF_DIR is nrDIR. nrEF_TRANSFER: The number of entries in EF.TRANSFER.

Figure 1 shows schematically the structure of the chip card according to the invention. In addition to the persistent, unchanged data used during the processing process, such as the MF Master File and the (optional) DF_PURSE portfolio function, there is further an index or data structure or information structure in the map according to the invention DF_VAS data. This serves to achieve additional features, the so-called payment computer services, VAS. Based on these additional features that allow requests that, even at a later stage, as it is said after the card was created (produced), can be introduced into the card, the card is variable and variant with respect to its functions and transactions that can be made afterwards. The so-called VAS media (DF_VAS) implemented in the chip card according to the invention allows the variability and variability of the chip card with respect to its functions and, moreover, transfers the requests recorded in the chip card, technologically protected by the card on the card, turning them into independent of the card on the card and even allowing them to be exchanged (transferred) to another card.

The new computer features according to the invention (Payment Computer Services, VAS) are implemented through microprocessor chip cards. Changing these additional features is caused by the VAS media. The VAS media in the microprocessor chip allocates storage space for VAS requests. Your VAS requests are accordingly implemented by specific computer functions.

In the case of an electronic portfolio, card-based payments (payment function) and the use of a VAS request (computer functionality) are represented through separate mechanisms. From the cardholder or cardholder, this can sometimes seem like a stand-alone procedure.

The microprocessor chip is expanded through a VAS media that can store a variety of independent requests, they can only be used through the authorized (authorized) system operator. The VAS media is independent of the other system components in the microprocessor chip in terms of data and security technology. The VAS carrier is entirely self-defined and functional in its own right. It defines an independent security architecture, so VAS. applications use independent security features. The security architecture (system) uses specific card keys that are specifically reproducible and that are independent of the card's card identification.

The VAS carrier also utilizes mechanisms for obtaining terminal specific keys. With these means, the VAS carrier itself can actively control the authenticity of the terminals, respectively. of the data submitted by them.

In VAS media VAS requests are introduced, both through the mechanisms of VAS media that make the data accessible, and by controlling the located interface points. The VAS carrier also enables and controls the protection of mutual exchange of mutual services data between partners. The VAS carrier actively takes care of the control, ie. the authenticity and uniqueness (of a single path) of the information values exchanged.

The advantage of VAS media over other attempts at multi- (multi-) card applications is that this concept is independent of the specific card on the card. It offers a security architecture that is independent of the specific security mechanisms of the board (such as keys, identities, PINs, signature procedures).

Another advantage of the VAS media concept is that the number of individual requests on the card is not strictly determined by restrictions and recommendations at the time of making the card or putting it into use (use). The generally accepted request card loading can be freely selected by the card user and is limited only by the available capacity (volume) of memory in the specific card. The number of VAS requests entered into the card for a certain amount of time depends on the actual use of the card. The card user individually enters (loads) your VAS requests into his card. This also causes the combination in the next instance to be modified. The VAS media allows a multifunction card in which the functionality of the card over the life of the card can be accumulated and used in various ways, given the number and nature of requests. It is also possible to introduce (load) a single request card, which in the past required individual special cards. Your requests can also be exchanged with other cards. Accordingly, VAS requests can survive after the card life cycle, they accompany the card user during the life cycle of the same requests.

The microprocessor chip with computer services is a necessary tool for distribution and commercial services to which data protection should be accessible. This microprocessor chip can be used as a means of payment, a calculator and for storing values. It can be provided with computer services and used to control them in accordance with the wishes of the customer by himself and after the card has been inserted in a flexible manner. It also actively controls the authenticity of the participating terminals and protects the uniqueness and authenticity of the data exchanged.

Figure 2 shows a diagram of the system. It illustrates the components of the system. The system operator makes the system accessible. VAS requests can be entered, retrieved, and exchanged by service terminals (STs), subsequent operations are distribution, review, processing, etc. of your requests.

The VAS contractors, the so-called VAS contractors, formulate their own VAS requests according to the basic conditions of the system operator and, if possible, to their own wishes. Corresponding terminal programs can follow 7

/ important to control the authenticity by digitally terminated (closed).

Figure 3 illustrates the data flow in the system.

Your VAS requests have been made available for use by cardholders at the terminals through the system operator. VAS applications may be recorded in the VAS of the chip card of the invention prior to participation, in this sense, being possible 10.

From the dealer terminal (HT), the VAS requests existing on the card are used either by the request or by the output of the VAS data. 15

In order to implement the microprocessor chip with VAS functionality, the VAS medium is implemented on the card in addition to existing requests (ie payment requests such as an electronic wallet). 20

The VAS media uses features that allow you to enter, display, or exchange VAS requests. These administration operations are exclusively used by the system operator and are protected in the card against future use. The VAS media includes a data exchange memory, the means of which exchange information between your VAS requests.

Both the TRANSFER and THEN 30 commands are used to control the memory for exchange. The TRANSFER command manages the entry into the memory for the exchange of specific data for the respective request. In addition to the data used, it also includes inputs such as, for example, data, deleted data, and the identification data required to control operations. Using the YES command, tasks are retrieved from the memory to be exchanged and marked as being retrieved. In accordance with the specifics of the application, the applications are then marked either to remain valid or to be considered invalid. The data exchanged is controlled by the VAS medium in accordance with authenticity and uniqueness. 45

VAS requests use VAS data to access and control requests. Access to VAS data is controlled through a VAS request, using the mechanisms that are valid for all requests in 50 VAS media. The VAS contractor processes one or more VAS requests in the VAS media.

The use of a VAS request is defined by entering, reading, and operating VAS data.

The VAS carrier supports mutual (external) services. Mutual services require exchange of information, exchange of requests for services and billing of services between different partners.

Further, the services and requests made possible through the chip card according to the invention will be considered with the descriptions (citation) of examples.

In each case, the description relates to the realization and action according to the present state of the art. In the future, the action will be illustrated by one or more VAS requests.

First, internal requests will be presented.

Example A: Buyers Club.

A department store organizes a customer club. Buyers become members of the club and, accordingly, receive specific club services that are not accessible to non-members. The club member is now identified in the club community by a club membership document. The club membership document is prepared on admission and is permanent and, as a rule, has a limited duration. Non-specific transactions are made through the club membership card, ie has no relationship with abandoned buyers. In this way, the club membership card is distinguished from bonus (incentive, bonus) programs in which there is a relationship between status and cancellation.

Analog: Wholesale membership card, senator card, reader card (for a library or book purchase).

Task: The club card is for proof by request in your VAS media.

Example C: Bonus system (incentive, for additional rewards).

The buyer is credited for every transaction with an extra fee - a bonus right. Bonus rights arise and can be converted to monetary gain during the buyer's decision. The Bonus Right is valid for a fixed period and can be administered anonymously or through the person to whom it applies. Bonus rights arise when canceled or expedited.

Analog: Points for Food & Other.

Task: The point sum must be administered by request in the VAS medium.

Example C: Reflection.

The buyer receives a list of rejected rebates. The rebate is attached (attached) to each individual transaction. The card does not administer bounce history. Each transaction is standalone (on its own).

Task: The right of rejection to be authenticated through your VAS request.

Example D: Identity of an action document.

The person (the client) has the opportunity to prove up to three times his / her right to predefine the services by means of the card. The linking of the person to the identity document (identification) must be authentic for each transaction (photo, PIN, biological features - biometrics). The authenticity of the identity document is used as a security feature.

Analog: Internal access, intra-bank access, telephone card.

Task: Permission must be exercised by your request.

Example F: Custom billing (receipt).

Use of the service is recorded for a period of time, frequency or quantity and is invoiced in accordance with the movement. The extent to which the service will be extended is unknown in advance.

Analogue: Food coupon, short-term parking ticket.

Task: Via your request to allow invoicing according to established tariffs. The billing request data at each specific level is entered into the VAS medium.

Example G: Data Recording (Mobile Database).

This request allows the cardholder to exchange data with the VAS contractor. Transactions are, however, automated, which must still be done manually. Non-monetary exchange can be obtained from this data.

Analogue: Filling in the numbers of swimming pool coupons, market sheets, cash receipts, telephone registers.

Task: The VAS contractor retrieves data from the card only when it is possible to directly perform the ordered service (making a telephone connection, making a list of desired purchases, electronically filling in and recording the numbers of the swimming pool tickets). The information (data) can be entered into the card for a short period of time or for a long period.

These examples of internal services will now be followed by several examples of external (mutual) services.

An external (mutual) service occurs every time many of your VAS contractors participate in a service. There is a constant connection of one VAS contractor to the rest of the known data. There are paper records for information.

Example A: Travel reimbursement.

A department store refunds to the buyer the amount of a passenger ticket issued by the public transport undertaking for the trip to the department store. The buyer can travel to the department store with a single travel ticket. The department store notes on the ticket that it needs to be restored (the funds for it). This is because the department store receives part of the customer's return from the transport company.

Task: The recovery procedure is done electronically.

Example C: Travel document (transport ticket).

The department store refunds to the customer, when making a purchase, the price of the ticket for the journey home through a payment document issued. The buyer receives a ticket from the ticket office of the public transport company or pays a reduced ticket price. The transport company invoices the payment document of the department store.

Task: Improve mechanisms through VAS requests (by introducing electronic invoicing between merchant and public transport company).

Example C: Customer parking.

The department store reimburses the customer (buyer) for part of the parking fees when using a private parking garage9. The parking garage is operated by an independent company and receives a cash payment from the department store for every honor given to the buyer.

Task: Simulate mechanisms 5 through VAS requests by introducing electronic bill submission between the merchant and the parking garage.

Example D: Multilateral bonus programs.

A group of commercial enterprises and service providers agree on a joint bonus program.

Task: Each partner can give or receive bonus points against an available account or card. Payment for services between partners is made through a subordinate system.

Example E: Recognition of bonus points between service partners.

Each service provider implements its own program, but participates in collaboration with others to recognize points collected. Examples of agreements between car owners and airlines to collect travel expenses are known.

Task: Make bonus points exchange through the card. Each VAS contractor is assigned to collect his points for himself without the intervention of anyone else. Mechanisms are provided to create an opportunity for exchange.

Example F: Taxis at night.

By purchasing a travel ticket from the public transport association, you simultaneously acquire the right to travel in a collective taxi (for example, after 10 pm). In order to fulfill the planned taxi company, it must be borne in mind that a travel ticket is presented. The use of fees shall be noted on the ticket in order to avoid misuse.

Task: Your VAS request is intended to allow the use, control, and provision of this service. 45

As follows, the structure of the chip card according to the invention will be described below.

In particular, the microprocessor chip with VAS functionality contains a VAS carrier 50.

The VAS bearer arranges the request in its own right, and it exists either individually or sometimes in parallel with other requests in the card base card. The VAS carrier is completely self-defined and self-acting. It can be triggered on any card without always presenting the payment function. In particular, the independent security architecture is defined for the VAS medium so that VAS requests can use independent security functions.

Part of the currency (payment) computer services are transactions presented by the client at the terminals of VAS contractors. The VAS contractor has an interest in controlling these transactions, either for system control purposes or for the collection of statistics or other data. For possible optimization and unification of the information structures on the card, the use of specific request identifications is not recommended and the use of unambiguous VAS media ID applicable for the whole system is suggested. This number can be used by the VAS contractor to carry out the aforementioned functions, and this releases him from the obligation to administer through his own numbering system.

The security architecture of VAS media uses this advanced unambiguous ID system - especially to retrieve specific keys on the card. Using a specific card number would be possible in principle, but it is advisable not to use it because the VAS carrier will be implemented on different boards, this can in some cases be used to counter numbering systems.

The VAS media is loaded by the system operator and switched on through the card outlet when the VAS media is created. All this is destroyed when the VAS media is cleared and is then moved (transferred) from the system. The VAS bearer is considered to have been purged if it does not contain VAS requests and if the VAS bearer ID has been transferred.

During the entire exchange of VAS media from the old one in the new card, the VAS media ID is exchanged together with VAS requests. This exchange corresponds to moving the VAS media from the old one to the new card. After this procedure, the old card briefly stores your VAS media. The VAS media created in the new card was overwritten during this operation and thus cleared. From the moment the VAS media is exchanged from the old to the new card, no transformation of the pointing numbers into the basic systems of the VAS contractors is required.

Individual VAS requests can only be exchanged between two different VAS carriers under the control of the lead VAS contractor. During this action, the links between the VAS bearer ID and the VAS request are changed, which can be written to the VAS contractor base system.

VAS media does not contain individual attributes, VAS requests may contain individual data, the extent of which should, of course, be kept to a minimum for information security conditions and for improved memory utilization. VAS requests should, if necessary, store individually relevant data in the base system and create the link to the card through the VAS media ID.

Maintaining mutual services is the most important feature of your VAS medium. Mutual services allow access to known information, the exchange of rights for services and the presentation of services between different partners. The VAS medium should make them possible, while overriding the protection of internal service requests. The so-called VAS internal service requests are requests that are processed under the sole control of the VAS contractor. The VAS contractor defines the security of their implementation, regardless of any external interference. Outsourcing may modify your VAS information without a key.

For effective mutual service delivery, partners should (would be desirable) to have access to the information available. Shared (Simultaneous) access to data is accomplished through a number of step-by-step security mechanisms.

The first step for simultaneous access is exclusively through the publicly available exchange areas. VAS contractors can interchange data across these areas without knowing each other's queries and needing keys. Only terminals need the appropriate keys to enter data into the exchange areas, but not read. Anyone can read without restriction. A mutual exchange of information can be done in both directions between the VAS contractor and the partner, if each has his or her key valid for entering information. The information exchanged can be downloaded from a VAS internal service request by your VAS contractor or vice versa, the VAS contractor can enter information from the exchange areas into your VAS request.

The second phase is the deletion of monetary values (foreign exchange) represented by VAS information. The VAS contractor enters the monetary values into the VAS information using a special key for entering information. Foreign currency funds can be consumed (used) through mutual-service partners who have a valid key to clear (liquidate) funds, carried out by a fully responsible VAS contractor. At this stage, partners with mutually different rights interact with non-accessible VAS information.

The third step is direct information input to VAS information from all participating mutual service partners. This method requires a degree of trust between the partners because your VAS information can be modified without restriction. The exchange area serves as a liaison between your VAS requests. Data in the exchange area is reproduced through VAS requests in VAS media. The data may, moreover, be entered directly into the exchange area if the person performing the same does not process his own VAS request in the VAS medium.

The exchange area is generally accessible to all requests, of course, entries can only be made by someone with the right to do so (for example, by key). Only recipients who are entitled to do so through the rules, the so-called R&D Rights and Regulations, can move information from the exchange area. The recipient checks for the presence (presence) of exchanged data addressed to him and downloads them for use in his own system.

In particular, to prevent manipulation of the information exchanged in a publicly available exchange, the manufacturer enters a sign of authenticity and enters a serial number for the VAS medium. These elements protect the uniqueness (only one) of the exchange solution and show real information.

If necessary, the recipient of the data exchanged shall be provided with a means of authentication by the manufacturer. If this is not done, the reception of the data may be done on a voluntary basis, in which case the authentication sign can only be verified when the execution starts in the base system of the working VAS contractor.

Downloading data from the exchange area is only possible once in the absence of a sign of authenticity. During the download, the data is tagged and left (as a copy) in the sharing area.

This allows the exchange procedure to be checked only after the information has been downloaded for a certain period.

The data in the exchange area contains the retrieved information. By means of arbitration requests, the extracted information may be overwritten where necessary. Data in the exchange area can be tagged on retrieval, which is free for immediate rewriting. However, if the memory of the exchange is to be completely filled up before the information exchange link breaks down, the cardholder must cut off the terminals of the terminal for services that are no longer needed.

Three operations are defined for modeling (shaping) VAS requests. These operations affect your VAS information. Input and output are functions of the VAS media and are not addressed in the following paragraphs.

Purchase: Generally, the purchase of a service right and the submission (proof) of proof of this in the VAS data of the VAS request.

Cancellation: Usually, payment of the right without or with full or partial consumption of the VAS request data. The procedure involves an electronic method (instruction) which is requested in the exchange area. This instruction transfers the assigned retrieved information, after which it can be deleted from the exchange memory.

Output: Generally create an electronic instruction in the exchange area for further action (the so-called base system). A copy of the instruction remains and serves as a check for "Cancellation".

The "receipt" of VAS information can only be performed through the respective VAS contractor. The “cancellation” of VAS data can be done through the VAS contractor who created it through “Purchase” or through a mutual service partner for which the VAS contractor is authorized.

The "output" can also be performed through some other VAS contractor. Mutual service without equal access rights to VAS information costs retention by the partner for a transitional period of the Output status. The electronic instruction by which it is discovered can then be submitted through the VAS contractor system operator and base system. Buying and Cancellation can be done in a stand-alone step.

VAS requests with known attributes can be divided into separate groups. These separate groups form the bases of information structures in the VAS media. The VAS contractor stores (saves) the request group during the execution of its request.

In this context (in this sense) the following query groups are defined:

• Point database • Ticket • Identification document • Payment document

Information database

Point database means a group of queries in which point calculation is administered (archived). Credit points can be credited and downloaded to and from point value accounts. Value crediting is done through the VAS contractor, which is why a balance of new accounts is entered in the information database. Debt values are entered through a "cancellation" operation, in the context of which electronic receipt (receipt) in the exchange memory is claimed as evidence. Access to both actions is allowed 12 through two different access keys.

Ticket means a group of requests in which the value area indicates what can be canceled and how it can be consumed in both cases, once or repeatedly. 5

The crediting of values in the Ticket Request group is only performed once.

Identification document (ID) means a group of requests where your VAS data receives proof of entitlement. The proof is usually not invalidated when used; of course, after a predefined criterion, i. after expiration of time, it will be declared invalid. According to the definition of the request, the authenticity of the identification document (ie a parking permit in the neighborhood) or the act of presenting the document is documented (ie collective taxi trip using a monthly ticket (subscription card): Issuance of an electronic receipt via the chip card. The receipt is presented by the taxi company of the public transport association and is reported in a proportionate manner.). Optional use of an identification document can be documented in the memory for exchanging the card electronically.

Payment document means a group of requests by means of which the service right (as a rule, for a short time) is placed 10 for temporary storage on the card. These electronic payment documents are stored exclusively in the VAS storage medium. The request using the payment document is, as a rule, different from the usual request. Withdrawal of the payment document from the storage place for exchange is possible only once and is documented on the card. During the calculation in the base system, the authentication sign created in the VAS medium may be used.

Database means a group of queries in which the VAS contractor remembers the data in the VAS medium to provide computer service to the customer (i.e., past menu at a fast food restaurant, past number from a swim number, service benefits, lists of suggestions ). This information is for information only and does not represent a right to the services of the VAS contractor. Data access is controlled by the VAS contractor.

Each request group is characterized by a typical usage cycle. The following table illustrates the frequency with which the three newly defined operations are applied to the VAS of a request group. (Please note: "Purchase" does not imply "request entry" and "download" does not imply "delete order").

Usage cycle

Table 1.

Point database Ticket Identification document A payment document Information database Buy Cancellation Download Multiple Multiple Multiple Single Multiple Multiple Single Multiple Multiple Single Single Single Numerous *** Never Never

♦ ** The database database query cannot be acquired, the query simply enters the query data.

Figure 4 shows the groups of orders and transactions explained above through a transaction model.

As follows, the secure architecture of the chip card according to the invention will be shown. The following keys are defined for security:

Table 2.

List of keys

Name Place Holder Description KSO KAUT KSIG _ VASC KGKDEC KLVASP KRVASP KGKDEC.PIX KDEC VAS carrier VAS carrier VAS carrier VAS carrier VAS request VAS request VAS contractor Dealer terminal System Operator System Operator System Operator System Operator VAS Contractor VAS Contractor VAS Contractor VAS Contractor VAS media administration key VAS media authentication key Transaction data encryption key KGKDEC.PIX key acquisition key VAS data write access key VAS read access key KDEC key acquisition key for the authenticity of the dealer terminal

The security architecture is based on the lifecycle of VAS media or VAS requests and is being built to suit the convenience of the parties involved. The schematic explanatory illustration is apparent from FIG.

As follows, some clarifications have been made on the structure of VAS carriers, as well as on their respective requests.

The VAS media, as well as the VAS specific computer commands, are entered together into the card through the card outlet together with other non-VAS requests, or are mostly integrated through the service terminal by the authorized (authorized) VAS contractor in the existing card board inserted in the service terminal.

For the second option, the following mechanism may find a request: The system operator agrees to the KSO * temporary key with the card outlet. The outlet opens the card with its key, which is known only to it, identifies the areas of the VAS media and more precisely writes KSO * to DF_VAS. The system operator may then, from a later instance (ie, the card come into contact with the first-time service terminal), move the KSO * key through its own KSO, which is known only by itself. The system operator can now enter additional data for itself, such as KGKDEC, or administer in the sulci of a dynamic memory card, or clear VAS request files. This is so secure that the opening does not have long access to the VAS media after the first use of the VAS card and that only the system operator has access to the VAS media. Due to the absence of some known information structures and the interchange of data with other requests, the security architecture of the VAS media is thus independent of other realized requests in the card board.

It is of course advantageous to do so at the earliest opportunity. The aperture is required by the instructions of the system operator to assist the VAS media in loading all the keys in the VAS cards.

The VAS media has a predefined information structure, predefined access coordination (ACS), and a certain amount of publicly available information. This information contains the so-called KSO key for entering or deleting VAS requests. It is protected by this key, known only to the system operator, where only allowed VAS requests can be entered. For this purpose, the card satisfies the condition of external authentication of the system operator to the KSO.

Sometimes the cardholder wishes to enter a VAS request from a service terminal, the respective VAS contractor instructs the system operator to do so on its own behalf. When a VAS request is entered into the VAS medium, the VAS contractor exchanges the KLVASP and KRVASP keys with the system operator, who then enters them into the request. The KLVASP key allows the VAS contractor to protect the request data against write access and accordingly protect the inside information against read access. For this purpose, the card satisfies the external authentication condition of the VAS contractor based on KLVASP: ie. the card actually checks the authenticity of the terminal. Following the successful implementation of this function, the terminal is allowed access to write a VAS request and read access from the internal VAS request information. Internal authentication, ie Verification of your VAS request (and thus of the card) as well as authentication through the dealer terminal may be optional. When a VAS request is used by a cardholder, this internal VAS data can be stored in the request or modified by arbitrary terminals that have access to the KLVASP switch.

The Purchase function is applied for this by the UPDATE RECORD command, which must be preceded by an external authentication using the KLVASP key.

Read access to all non-internal VAS request data is only used if the previous external authentication was performed by KRVASP or by correcting the PIN or password input from the system operator. Protected PIN / password access is intended to allow the cardholder to revise data from the terminal or the wallet. From a service terminal, the cardholder may decide to activate or deactivate PIN / password protection to read values or status data.

Publicly available VAS data is matched with the KSIG_VASN key to mark the output of the exchange area. By virtue of the signature, the integrity of these transactions can be verified each time they have to be protected against manipulation when exchanged between their mutual partners for a mutual account. In addition to the signature, optionally entered by its mutual partners, the signature is based on KSIG_VASC and a transaction counter administered by VAS media, which is supported by groups of data selected from the card by the download operation. Because of this, on the one hand, the readout of the exchange area is executed by someone else, but on the other hand, the card signature through KSIG_VASC can only be created when called for a download operation (and this can happen only once), any unauthorized duplicate used for a payment document is recognized. Each of the mutual service partners may have the authenticity and uniqueness (to be the only one) of downloading a payment document confirmed by the system operator. In addition, the authenticity of the VAS media can be established by verifying the signature of the system operator.

If the card board uses asymmetric key procedures, it is also possible to use the card as a KSIG_VASC own (secret) key to indicate the intent (tasks) or to create such a key from its own KGK Key. VAS contractors can also use commonly known (non-secret) keys for their own signature verification in the same case without consulting the system operator.

Some of the VAS media data is generated through the well-known KGKDEC Key Generator Key, which has the ability to create the KDEC access key for all terminals of all VAS executors for authorized revocation operation (creation of dependent key and verification will be performed again as below). The deletion of monetary value data is not subject to certain safeguards such as the introduction or purchase of a right to something. For this purpose, it is sufficient to use the well-known key instead of the specific query key. This commonly known key is first converted to a query key and then resumed to a terminal key. The VAS contractor is only for the specific request creation from the commonly known key to create its own terminal key. This is briefly described as follows:

We denote as mac (k, d) the calculation of the transmitted authentic message code d and the DES key k by means of DES. As long as the message is not 8 bytes long, this corresponds to encoding, such as (assuming ICV = 0).

/

We denote as macp (k, d) the calculation of mac (k, d) with subsequent adaptation of an equal number of bits. The result k '= macp (k, d) is once again a valid DES key. The calculation of the specific terminal key of the request continues as follows:

1. Each card stores a key

KGKdec, which is the same for all cards and which keeps the secret through the system operator. The system operator acts to personalize this key on the card. All other VAS request and terminal keys can be created from this key.

2. The VAS contractor wishes to enter VAS request A with AIDa = RIDvas.PIX _a . The system operator now calculates the specific request key from the KGKdec key and the PIX key

KGKDEc.PIX = macp (KGKDEc.PIXA) and passes this key to your VAS contractor.

3. This VAS contractor, through the means of its (request) terminal ID, generates from KGKdec.pix for all terminals whose TRANSFER command is assigned to implement in VAS application A, its (request) specific keys:

KDEc = macp (KGKdec.pix, Terminal ID) = macp (macp (KGKdec, PIXa) .Terminal ID)

Your contractor stores these keys in their terminals. In case the VAS contractor does not manage the terminals on its own, it creates keys and distributes them to the terminal operators.

4. The VAS card only executes the TRANSFER command if the command contains a cryptogram (encrypted text) C generated by the terminal, which is formed by the specific data - the message data in the exchange memory. The card itself recognizes KGKdec and receives from the terminal instead of message data and cryptogram C, the terminal ID also PIX (or alternatively the card itself knows PIX, for which it only sees the description of the TRANSFER command). The card can now calculate the cryptogram C 'using the user's data:

mac (macp (macp (KGKdec.PIX), Terminal ID), data) = mac (macp (KGKdec.pix, Terminal ID), data) “mac (Kdec, data) = C '

The card compares the crypto C 'calculated by itself with the crypto C calculated by the terminal. If they are different, then the deal is terminated and the message is wrong. In case of compliance, the VAS card will execute the TRANSFER command.

The security options are consistent with the different designs of service or dealer terminals (entry or purchase respectively) and ordinary dealer terminals (cancellation). In order to perform the cancellation operation, a terminal must prove its authenticity on the card by recognizing Kdec. If this Kdec key is compromised, the aggressor can simply perform the action from this single terminal. However, this procedure is recorded on the card. The documentation contains a unique serial number, cancellation and terminal ID. VAS requests use security services from VAS media to regulate the exchange of VAS information. The implementation of VAS specific functions is limited to authorized parts of the definition of access rights.

In general, it is necessary for each VAS request to have publicly available information areas (ie, to read values through portfolio assets) and the own information areas of the respective VAS contractor, which can last build protection against third party access (t .e. to internal administrative information).

Considering the fact that according to ISO 7816-4, the cards do not provide a differentiated access advantage for individual Elemental File (EF) records, it is necessary to use multiple files, each containing a record for exposing different sides of your VAS request.

Thus, for the Score Record, Ticket, Identification Document and Information Database groups, differentiated secure access can be enabled by splitting the VAS data into four Elementary files, as shown in Fig. 6.

The four Elemental files contain the following information or are protected as follows:

Table 3.

File summary

District Content Typical use Access protection EF.KEY Contains the Klvasp key, Krvasp, which is known only to the VAS contractor (3Note: 3a for each VAS request and optional for each card, the VAS contractor creates one key pair) The VAS contractor must prove its authenticity to Klvasp before being allowed to record VAS data in EFJNFO, EFJNTERNAL and EF.VALUE, respectively. before being allowed to read EFJNTERNAL data, the Terminal must prove its authenticity by means of Krvasp, before being allowed to read your EFJNFO data, EF.VALUE EFJNFO Insider information through your request 'Ticket information ♦ Bonus program information ♦ Identification document information ♦ Parking ticket information The contents of these information parts can only be recorded by the VAS contractor (internal authentication by Klvasp recognition). Reading would only be possible from terminals with access to Krvasp OR Kso, or if the cardholder enters a valid PIN. (PIN protection can be deactivated by the cardholder.) EFJNTERNAL Insider information on your request Internal counters, accounting messages, fee information, computer keys for: ♦ Bonus programs От Reflection tables ♦ Hidden identification signs ♦ Codes The contents of these information parts can only be recorded and read by the VAS contractor. Access security is based on internal authentication by Klvasp authentication. EF.VALUE Cash on your request This information section contains the estimated values by the VAS requester Only the VAS contractor can record this data explicitly (external authentication via

* Accounting messages * Remaining cash from the public transport ticket • Credit • User counter recognition by Klvasp). Of course, the cash can be reduced through the cancellation command of the partner who was given the right to perform the action through the VAS contractor (via the Kdec cancellation operation signature). Reading as for EFJNFO.

This Element File (EF) structure sets some differentiated access permissions for all query groups.

Given that query groups are now combined into a single runtime group that formulates the number and size of Elemental files, the amount of memory space corresponding to the different query space requirements can be minimized. The Query Memory and Ticket request groups require the known resources EF_KEY, EF_INFO, EFJNTERNAL, EF_VALUE and are respectively combined in * DF_PT 'execution group. For Request Groups Identification Document and Database Elementary Files EF_KEY and EF_INEO are sufficient and are respectively combined in the * DF_AD 'execution group. Viewed by number: there are p tasks in the * DF_PT 'execution group, and there are p tasks in the execution group' DF_AD 'in your VAS requests from the request groups memory and ticket respectively. identification document and information database (p and a) that can be entered.

Specifically, the payload group ₄ θ voucher, which should be created for public reading by all VAS participants for joint exchange purposes, is used by the Execution Group exchange area. Recording access 45 is only possible indirectly by applying the TRANSFER command, which implies a signature with the correct KDEC. This runtime group consists of exactly one entry into the EF_TRANSFER Elemental file, 50 belonging to the publicly available information on VAS media. The tasks of this group are written in this file. We refer to this implementation group in the same way as * EF_TRANSFER '.

The implementation groups shown in Figure 7 exist in the VAS carrier. These performance groups form the VAS memory model.

The memory model can be made valid in two ways. The conversion depends on the card on the card.

Fixed allocation of VAS storage (storage) area:

For the DF_PT and DF_AD execution groups, the maximum number of p or a, the case may be the following: for tasks - fixed by the card outlet and entered through the card outlet using CREATE FILE commands. Tasks are defined as DF_PT and DF_AD respectively. VAS requests can be entered later in job-free locations, ie. not involved in other VAS requests. Then only UPDATE RECORD commands are required to enter or output your VAS requests.

The opening thus fixes the number of possible tasks for the two performance groups according to their own needs; this can sometimes distinguish the cardholder from the actual VAS user. The division is maintained throughout the life of the card. Your VAS request is entered into a task belonging to the respective execution group. For example, a VAS request representing an ID can only be implemented in a DF_PT runtime task if there are few tasks in the runtime group

DF_AD are valid. Joining a VAS request to a task is accomplished by entering an obstacle (PIX of the VAS request, the FID of the entered task, the exact text name of the request) in the publicly available EF_DIR database on the VAS medium. The relocation of the request is consistent with the removal of this obstacle by EF_DIR and the broken (interrupted) reading (via UPDATE RECORD commands) of information entered with the request.

This modification is used with card boards that do not dynamically create or clear DF / EF structures.

Dynamically assign tasks to the execution group.

For each VAS request to be entered, files are generated using CREATE FILE commands as a necessity for the primary (hidden) execution group. When the VAS request is displayed, the DF / EF occupied by it is transferred entirely from the card and the storage space is released. The maximum number of tasks in the execution group here is not explicitly determined by the outlet and depends only on the amount of memory of the valid card.

This modification implies dynamic administration of the database information from the operating system of the card.

In the next job tracking example, we will start with the first modification, because the next one raises important questions before the available card on the card. Of course, if dynamic storage administration is possible and it is possible to retain more memory by assigning tasks dynamically to the administration costs, then the existing design can be perceived and offer more flexibility to the cardholder.

As follows, information structures and commands are represented by means from which the VAS carrier and the operation of the client's VAS card can be implemented in combination with other system components. Moreover, VAS operations are formulated through 10 typical business situations that describe the corresponding interaction between the VAS carrier and the terminal.

The following preconditions apply to the implementation:

* Each card, regardless of the card, makes it possible to transmit the specified amount of data and commands from the dealer terminal. Accordingly, the commands created are precisely described in their encoding.

* Service terminals are required to identify the card on the card. In doing so, the action can be accompanied by specific commands on the board. Accordingly, these transactions are partly recorded formally. The way this action is performed is independent of the map creation.

In this context, FIG. 7 is a schematic representation of an embodiment of VAS carrier groups. FIG. 8 shows schematically the information structure of the VAS carrier. Fig. 9 shows schematically the information structure of the implementation group DF_PT, Fig. 10 shows the information structure of the DF_AD group.

Access to VAS media files is explicitly restricted by the following access conditions (ACs):

Conditions of access

Table 4.

Information database Administration Read access Recording access DF_VAS Kso NEV NEV EF_ID Kso ALW Kso EF_DIR Kso ALW Kso global KEYs Kso NEV Kso PIN Kso NEV Kso EF_VERSION Kso ALW Kso

EF_SEQ Kso ALW Kso EF_TRANSFER Kso ALW Kso DF_X (X = PT1, .., Ptr, ADI, ..., ADa) KSO NEV NEV EF.KEY Kso NEV Kso EF_INFO Kso PIN or Krvasp or Kso Klvasp EF_INTERNAL Kso Klvasp Klvasp EFVALUE Kso PIN or Krvasp OG Kso Klvasp

In this context, the AC has the following meaning:

ALW (Always) «Command access to the database is always allowed.

• NEV = Command access to database information is never allowed.

• Kso = Prior to access, the external authentication of the system operator must be established using the Kso key.

• Klvasp = Before access, the external authentication of the VAS contractor must be established using the Klvasp key.

• Krvasp = Before access, the external authentication of the authorized (authorized) terminal for your VAS contractor must be established using the Krvasp key.

• PIN = Before access, the correct PIN must be entered by the card holder and freely transferred to the card via the VERIFY command.

• PIN or Krvasp or Kso = Prior to access, either of the following must be completed: the correct PIN must be entered by the cardholder or external authentication must be established through your VAS contractor using Krvasp or through the system operator using Kso.

In this sense, it should be noted that OR the linking of access rules in the current card system, as emphasized, is not fulfilled. Where applied, this would entail special additional costs (alternatively: a special READ command with an unconditionally fixed security feature).

The information areas inside the Elemental records are differentiated according to the following formats: ASCII, 15 Binary, BCD, Date, Format string.

Format string information elements contain VAS information in a batch representation that can be displayed to the cardholder on ter2θ past.

For optimal representation of stored information, the exact text and binary data are mixed and reproduced on the display using formatting macros.

All Elemental Files (EF) on VAS media are defined according to ISO 7816-4 as a linearly formatted EF database of constant length records (linearly fixed record files).

The elementary file EF_ID of DF_VAS consists of a record that contains the VAS media ID.

The EF_DIR element file of DF_VAS consists of nrDIR records. For each VAS request entered into the VAS medium, its suitably identified state (PIX) and its physical storage location (the FID of the DF_X in which the request was entered) is fixed in the EF_DIR record. PIX, ie as the code number, identifies the request and the service provider for which the request was intended.

The EF_DIR twists are dynamic system operator interruptions from a service terminal. Entries without entry are inclusions with empty (no content) TLV task '61'.

When a VAS request is entered, there is obviously a free storage area for the execution group, the known VAS data is entered there, and a new entry in EF_DIR is created.

When querying, an empty (no content) TLV job must be saved to EF_DIR in a consistent manner.

The elementary file EF_VERSION of DF_VAS consists of a record that contains a variant number of the VAS media.

The variant number can be used through the terminal to differentiate between individual VAS media modifications and / or individual software versions.

The DF_VAS elemental EFJSEQ file consists of a record that contains the next entry in the exchange area.

The serial number is read by the TRANSFER accompanying command. This command then creates an entry in the exchange field EF_TRANSFER, in which the mutually fictitious serial number of EF_SEQ is exchanged. In conjunction with the YES command, which ensures that for each record in the exchange area it is downloaded only once, this downloaded record is signed by a signature to the serial number, only once a payment document or receipt can be extracted.

The memory of the exchange is further discussed in more detail.

The exchange memory is a block inside your VAS media and contains nrEF_TRANSFER records. The entries in the records of these files carry data for the exchange performed by the TRANSFER command. The interchange of information (data) between your VAS requests, as well as the VAS data memory of the payment document group (Voucher) is represented through the memory for exchange.

The exchange memory can be read without restriction, although write access is only possible through the VAS specific TRANSFER and YES commands.

Entering information areas through the TRANSFER command is done using the “recent recent use” algorithm on the map. The old database entry can be determined by exploring (searching) for the lowest value in the first two bytes of the record.

Information areas can be marked using the YES command in the exchange memory such as download and / or transfer. In any case, the deletion (deletion) of data in the exchange memory is done by overwrite with new data.

Each exchange memory record contains, for example, downloaded data, terminal ID, PIX, serial number and optional additional data.

Each EF_INFO Elemental file within the DF_X lists (where X = PT1, ..., PTP, ADl, ..., ADa) contains a record storing the downloaded data as well as the basic VAS information of a VAS request. For example, the nature of the ticket (single or multiple ticket) or reserved seat information may be included here. EF_INFO, however, must finally save one exact text name of the request that can be read during the operation of displaying (on the display) of your VAS requests. Important information must first be protected by the VAS contractor through appropriate external key algorithms.

This EF can be read if there is established external authentication with Kso or Krvasp or it is specified where the cardholder enters the correct PIN in case of PIN protection activated.

Each EF_INTERNAL Elemental file in DF_X records (where X = PT1, ..., PTP, ADI, ..., Ada) consists of a record that can store internal VAS information for a VAS medium containing its VAS request. Neither the cardholder nor any other VAS contractor can read this inside information. Each EF_VALUE Elemental file inside the DF_X records (where X = PTl, ..., PTp, ADl, .. ADa) contains a record that can store an entire monetary value area of VAS information. This EF can be read if there is an established external authentication with Kso or Krvasp or the cardholder enters the correct PIN or correct password in case of PIN protection activated.

The following area keys are used by the VAS media or VAS request. Next, we will start with pure DES coding, i.e. all VAS media keys are DES keys and are encoded in 8 bytes (except for similar bits).

In the VAS medium and in the VAS request, the following mentioned keys can be checked using their KID.

Table 5.

VAS media keys

KEYS KID Kso '00' Kaut '01' Ksic VASC '02' KGKdec '03'

Each key is connected to an operational error counter. This registers ignored attempts to authenticate with this key and blocks any further use once a limited logon has been made for this counter.

In your request, the following keys can be checked using their KID:

flights that can be entered into your VAS at the same time.

• Maximum number of tasks from the execution group OR_AO «* maximum number of VAS requests from the request groups Identification document and Information database, which can be entered simultaneously in the VAS medium.

• nrDIR maximum allowed number for 10 dachas:

nrDIR = p + a

The number of entries in EF_DIR is nrDIR.

nrEF_TRANSFER is the number of entries by EF_TRANSFER.

The required amount of memory for the data described

The elementary files are as follows: Basic information

Table 6.

Keys to your VAS request

KEYS KID Klvasp '04' Krvasp '05'

on your VAS media: Bytes:

EFJD4

EF_DIR 9 * (p + a)

EF_VERSION1

EF_SEQ2

Main keys, RJ64 + 2

Areas of exchange:

Each key is connected to the operational error counter. This registers the ignored authentication attempts with this key and blocks any further use once a limited logon has been made for this counter.

Your VAS media contains your own personal identification number or password (PIN). This is used to identify the cardholder through a VERIFY command. The PIN is associated with an operating counter that registers any false startup and which blocks the PIN comparison to reach a limit. This blocking can be changed back by the system operator using the appropriate administration commands. The error counter has been reset once the correct PIN has been entered.

The following parameters are for VAS media, they can be selected by the card manufacturer according to the space available on the card board and his individual desires:

• p maximum number of tasks in the execution group OP_PT-maximum number of VAS requests from the request groups Point memory and Bi30

EF.TRANSFER Personal information of your contractor: EF_KEY (p + a) EF_INFO (p + a) EFJNTERNAL EF_VALUEp

8 * nrEF_TRANSFER ♦ 32 * 62 p * 10 * 3

If we specify, that is, for the parameters p, a and nrEF_TRANSFER, the following values, the following minimum amount of memory is required for VAS media (without the required amount of memory for additional commands):

Parameters: Required memory capacity:

p = 8, a = 3, nrEF_TRANSFER = 15 2030 bytes p-10, a = 5, nrEF_TRANSFER = 20 2758 bytes The maximum amount of memory required must be greater than at least about 10% of the minimum required amount of memory.

The chipboard commands according to the invention are discussed in more detail below.

The READ RECORD command is used to read information from linear Elemental files. In response, card50 fills in the contents of the records. EF was verified by the Short Identifier (SFI). The status code '9000' indicates the successful execution of the command; any code other than that code is considered incorrect.

The UPDATE RECORD command is mainly used to enter data into linear EF records. The command message contains the verification of the EF record and the data.

The map answer contains the status code. Status code '9000' indicates successful completion of command. Other status codes indicate an error.

The GET CHALLENGE command requires a random number from the card. The random number is used to connect to the dynamic authentication condition in EXTERNAL AUTHENTICATE.

The corresponding message on the card contains a random number of 8 bits in length and a status code. The status code '9000' indicates the successful execution of the command. All other codes show an error.

The EXTERNAL AUTHENTICATE command checks the terminal using the card. EXTERNAL AUTHENTICATE is used in the context of VAS authentication requests from your system operator and VAS contractor. EXTERNAL AUTHENTICATE exchanges a cryptogram in the card that was previously created through the terminal by encoding a random number. The card compares the cryptogram to a verified value that is calculated by itself using the same procedure. If both values are the same, the card internally indicates that exchange authentication for this key is available. If the result is negative, the card will indicate an “unauthorized” status and set an error for the internal operating counter. When this counter encounters a value of "0", any further execution of EXTERNAL AUTHENTICATE is blocked with the "authentication blocked" status.

The corresponding message on the map contains the status code. The successful execution of the terminal authentication command in conjunction with the card is indicated by the status code '9000'. Any different status codes indicate an error.

The INTERNAL AUTHENTICATE command is mainly used to authenticate VAS media through a terminal. The card calculates the cryptogram for this purpose by checking the data provided by the terminal. The terminal formulates the cryptogram in its call and compares it with the value of the card. In the case of uniformity, the terminal may accept the authenticity of the VAS medium.

The response on the map contains the cryptogram and status code for the command to execute. The successful execution of the command is indicated by the status code '9000'. All other status codes show an error.

The VERIFY command is used to confirm the PIN of the cardholder. The command exchanges PIN information decoded for the card, which compares with the stored verified value. If the entered and stored values are identical, the exchange conditions “PIN” are considered to be respected.

The corresponding message on the map contains the status code. Status code '9000' indicates successful command execution. Other status codes indicate an error.

The TRANSFER command allows access to the memory to be exchanged. The following three ways of sharing are defined for the command:

1. Permission to enter the exchange area by converting the values in the EF_VALUE request area for the Ticket Group or Point Memory.

2. Permission to enter the field of exchange by creating a condition in the request for the group Identification document.

3. Permission to enter into the field of exchange by creating a payment document in the application form of the Payment document group.

The mode of action is automatically selected from the map: If the command is executed inside the selected DF request, the representation of EF_VALUE is first checked. If EF_VALUE is available, the map executes the command in mode 1, in contrast to mode 2.

If DF request was not selected in VAS media, method 3 is used.

The terminal, when assigned to the TRANSFER command, loads the card with the following data:

• Current data;

Baseline entry data for the exchange area;

• Identification of the terminal that allows this entry;

• Useful information on the field of exchange;

• PIX of your request (method 3 only);

• Number of points to be displayed (mode 1 only);

• A MAC containing the above mentioned data, a serial number and a VAS media number.

The card, once the TRANSFER command is called, performs the following action:

1. Study on free access to the memory for exchange. (The following list reverses the priority in which existing entries should be overwritten: '' Entry marked as overdraft '', 'Entry marked as output' and 'Missing (lost) data encountered'.

2. Applying PIX to terminal data in Modes 1 and 2.

3. Applying the serial number to the data in step 2.

4. Applying the VAS media to the data in step 3.

5. Create KGKdec.pix by encoding PIX according to KGKdec.

6. Create Kdec by encoding the terminal ID according to KGKdec.pix.

7. Creating a MAC using the data from step 4.

8. Comparison of the MAC of step 7 with the terminal MAC. If the values are different, the card interrupts and subordinates the wrongly running KGKdec counter.

9. For Mode 1: Test the EF_VALUE cash value area in the registry where the request was entered. If insufficient funds are presented in this area, the card interrupts the operation at this point. In other words, the value field in the query is subordinate to that quantity.

10. Install the command message.

11. Removing the contents of EF_SEQ by 1.

The command message contains, for example, areas including; missing (lost) data, terminal ID, transaction data, area of action (contents, i.e., in mode 3, PIX), and cryptogram.

The cryptogram is calculated to use the Kdec key, the data generated by the MAC, 5 for example, including the transaction data and the terminal ID.

The response message from the TRANSFER command includes, when successful, an 8 byte length information area and a value of 10 for the '9000' status which is 2 bytes long. Response messages with a status code other than '9000' are considered incorrect codes. The response message information area contains an error-free position (i.e., more precisely, the cryptogram of the command message was correct), the cryptogram is encoded with KDEC by the command message. This way (KAUT is used instead of internal authentication). The condition of authenticity is unconditionally fulfilled by your VAS contractor.

The TAKE command serves to derive tasks from the EF_ TRANSFER implementation group. Technically, executing the YES command means that reading out of a record is noted by the EF_TRANSFER memory, the record is stored in the memory until there is a need for volume for new input. The information pack is marked as "downloaded". Technically, no one can use the YES command to download an information packet, but according to R&R, only the VAS media for which the information packet was intended could do so.

For the transfer (transfer) procedure, the following may be allowed: The VAS contractor, who wishes to transfer a payment document or receipt, seeks an appropriate information package in the exchange memory (ie through the SEEK command or by explicit reading of each record). The information package will in any case be read and its contents can be checked.

Accordingly, displaying the information packet is therefore unnecessary. The record number may at most be allowed to be known.

The YES command is executed for the following cases:

• Transfer at the same time noting that the information was invalid;

• Transfer without the specified mark. This means that the information is valid.

The command message contains areas with terminal-ID, request PIX, and a random number created by the terminal.

PIX in the command notes the request that transfers information. With PIX, it can be separated from the information packet that has been transferred. This serves exclusively to create a KDEC from the dealer terminal that handles the transfer.

The corresponding message on the card contains the cryptogram Cl with KSIG.VASC consisting of the information of the exchange records presented (transmitted) in the command message and the VAS bearer ID, the C2 cryptogram with KDEC at the terminal carrying out the C1 transfer and the random number carried by the command message. The corresponding message in addition contains a message code. The KDEC key is created as described above. Authentication is unconditionally fulfilled for the VAS media by KDEC cryptogram. Proof of authenticity and uniqueness (one time only) is calculated by means of cryptogram C (from C is formed by the serial number of the transfer bit of the record from the exchange area and VAS carrier ID), which can be verified and confirmed by the system operator.

Status code '9000' indicates successful command execution. Different status codes are considered errors.

It can be assumed that SO requires one AIDvas according to IDO / IEC 7816-5. In particular, it requires a 5-byte RIDVAS for the VAS system.

AIDvas from the list DF_VAS should read: AIDvas = RIDvas.PIXdf_vas.

For each VAS request A, a 3-byte length PIXa is allowed, in accordance with R&R, to unambiguously identify the first within the VAS medium by AIDa = RIDvas.PIXa. After selecting the DF_VAS list that contains your VAS request A, the use of SELECT FILE <PIXa> may be selected.

UPDATE KEY (KID, K) means a command that refers to a card on a card that transfers a key to a new value K using the key ID.

Before a VAS request is issued by one of the DF_PT or DF_AD execution groups (corresponding to the request groups Point Memory, Ticket, Identity Document or Information Database) and can be used by the cardholder at the dealer terminal, it must be entered into the VAS medium from a service terminal by an authorized VAS contractor. In principle, this is only possible when the card outlet instructed by the VAS contractor and SO enters one or more requests into the VAS media only when the VAS media is installed. Such a route of administration implies a special case that is described according to the invention.

Procedure for entering your VAS request:

1. The card holder places the VAS card in the service terminal.

2. The service terminal looks for where your VAS is located:

• SELECT FILE <AIDvas> (wrong answer if your media is not selectable);

• READ RECORD <SFI of EF_ID, 0> (VAS media number is displayed).

Optional, the VAS carrier is validated. For this, the service terminal requires the establishment of the internal authenticity of the VAS media:

• INTERNAL AUTHENTICATE <casual number, KAUT KID>

The service terminal looks for compliance and in the event of an error (with a display error) interrupts the procedure.

3. The service terminal offers the cardholder a choice of several options. One is to enter a VAS request. It is chosen by the cardholder. All VAS requests that can be entered from the service terminal have already been shown to the cardholder and the choice is awaited. For this purpose, the operation of displaying VAS requests is activated. The card holder selects a VAS request from the DF_PT or DF_AD execution group.

4. The service terminal checks the VAS medium through the operation of selecting a VAS request, and whether the selected VAS request has 25 ζ

, / ß ΡΙΧα, has already been entered on the map. When confirmed, the wrong signal is displayed. If not, make sure that the task of the execution group belonging to A has just been established in the VAS media. This refers to the search for a free place to write in EF_DIR (ie using the SEEK command). If nothing is available, the wrong signal is displayed. If there is free space for recording, this includes DF_X FIDDF_X in which no VAS request was entered.

5. The next free task from the execution group belonging to A is entered with VAS request A. For this purpose, the service terminal first requires an off-line from the VAS contractor (ie via the VAS contractor SAM) two keys KLVASP and KRVASP and notes them to the new VAS request:

• SELECT FILE <FIDDF_X>

• GET CHALLENGE • EXTERNAL AUTHENTICATE <KSO (Random Number), Kso of Kso>

• UPDATE KEY <KID by KLVASP, K RVASP>

• UPDATE KEY <KID from Klvasp, Krvasp>

• GET CHALLENGE

EXTERNAL AUTHENTICATE <Klvasp (random number), KID of Klvasp>

• UPDATE RECORD <SFI of EF_INFO of DF_X data>

UPDATE RECORD <SFJ of EFJNTERNAL from DF_X, data>

• Optional (Initialize): UPDATE RECORD <SFI on EF_VALUE from DF_X, data>

6. After successful introduction to the EFs, the service terminal performs the operation of entering VAS 3aaeka <PIXA, FIDDEX>, which connects DF_X to PIX and therefore executes SELECT FILE by means of ΡΙΧα (after pre-selection using SELECT FILE AIDvas).

The mechanism makes it possible, through the exchange memory, for example to be used by VAS contractors who wish to perform internal or reciprocal services without their own DF structures. The card holder, in particular, does not need to first enter it from a service terminal before using such a VAS request. On the contrary, it can bring to itself at the dealer terminal a payment document or receipt and have this option (privilege) from a different terminal (through the operation of transferring or only displaying the payment document or receipt (for reading). The EF_TRANSFER implementation group is therefore unconditionally performed by entering VAS information or triggered by the same operation. In this context, reference is made to the purchase description in the EF_TRANSFER execution group as follows.

The sequence of operations for entering VAS requests is described as follows:

If the VAS request was entered into the VAS medium, the terminal will not know the physical location in which DF_X, where X stands for "PT1, ..., PTp, ADl, ..., ADa, VAS request was entered or where it was introduced at all. From the card manufacturer's perspective, two possible runtime modes are allowed; in this context, proximity to the ZKA standard must be partially respected.

First case: Access to EF_DIR is possible.

The following recommendations should be considered:

• EF_DIR (ie from DF_VAS), in which AIDs are deployed with FIDs from DF_X, in which VAS requests are usually located, exists as standard in the card board.

This EF_DIR can be read by anyone (AC from READ RECORD: ALW).

• If VAS request A with ΡΙΧα is entered by the system operator in free (unused) DF_X, ie. entry is made in the existing DF_X Element Files (not CREATE FILE), it should then be possible to distribute the EF_DIR entry database for its input by the means of UPDATE RECORD, which refers to that DF_X via FIDX. The UPDATE RECORD AU should therefore emphasize the establishment of external authentication by means of the Kso key.

• If the SELECT FILE <PIXa> command after DF_VAS pre-selection is transmitted to the card, DF_X, in which VAS request26 has been entered, should be directly selectable.

• If the VAS request A entered in DF_X and its corresponding Elementary files is deleted from the service terminal at the request of the cardholder, the respective databases are not deleted through DELETE FILE, but the entered data are recorded only with dummy values. It is then necessary to delete the input PIXA from EF_DIR (in particular the PIXA pair and the reference to DF_X) (for example via UPDATE RECORD with pre-established external authentication using the Kso key).

• Once the number of DF_X is fixed, the number of EF_DIR records is known.

If this approach is feasible, the following results are achieved:

• Direct selection of your VAS request using SELECT FILE ΡΙΧα is possible after selecting DF_VAS.

Second case: Access to EF_DIR is not possible.

If part of the card on the EF_DIR card is unavailable or unreadable, or write access to that EF_DIR (as described in the previous paragraph is impossible), loading can be done under the control of DF_VAS for a database EF_VASDIR, to use ΡΙΧα to connect, to enter a VAS request at its physical memory location in DF_X, triggered by the system operator through explicit UPDATE RECORD commands (after externally authenticating via KSO) .Reading and deleting EF_VASDIR records would be possible as inventory but before.

The operation to enter a VAS request is as follows:

VAS request A including PIXA was first introduced into free DF_X with FIDdex. The record number containing FIDdex is noted by the service terminal.

1. SELECT FILE <AIDvas> (display error if VAS media is not selectable).

2. GET CHALLENGE

3. EXTERNAL AUTHENTICATE <Kso (random number), KID of Kso>

4. UPDATE RECORD <EF_DIR by DF_VAS, Record number c FIDDF_X, PIXA, FIDDF_X>

VAS requests from the DF_PT or DF_AD execution groups can only be deleted at the request of the cardholder from the service terminal (being under the control of the system operator), VAS requests from the execution group EF_TRANSFER can be deleted anywhere and by anyone. When deleted, it is necessary to distinguish between VAS requests from the DF_PT and DF_AD execution groups, respectively. the EFTRANSFER implementation group.

Deleting such a VAS request from the DF_PT or DF_AD execution group proceeds as follows:

1. The card holder places the VAS card in a service terminal.

2. The service terminal looks for where your VAS is located.

• SELECT FILE <AIDvas> (display error if VAS is not selectable)

READ RECORD <EF_ID> the VAS media is displayed)

3. The service terminal serves the cardholder with a choice of several options. One of them reads as deleting a VAS request. Selected by the card holder. All VAS requests from all execution groups entered into the VAS media are now displayed on the cardholder display and are expected to be selected. For this purpose, the operation of displaying VAS requests is activated. The card holder selects VAS request A from Execution Group DF_PT or DF_AD through AIDA means. The task with which your VAS request was entered is accepted to be marked DF_A.

4. After selecting DF_A, the service terminal shall authenticate.

• SELECT FILE <ΡΙΧα>

• GET CHALLENGE • EXTERNAL AUTHENTICATE <Kso (random number), KID by Kso>

5. The contents of DF_A files are now deleted (Klvasp is required for EF_KEY, EFJNTERNAL and EF_VALUE, the condition of which is first deleted by the system operator):

• UPDATE KEY <KID from KLVASP, "00 ... 00">

• UPDATE KEY <KID from KRVASP, "00 ... 00">

• GET CHALLENGE • EXTERNAL AUTHENTICATE <Klvasp (random number), KID by Klvasp>

UPDATE RECORD <SFI by EFJNFO from DF_A, "00 ... 00">

• UPDATE RECORD <SFI of EFJNTERNAL by DF_A, “00 ... 00”>

• UPDATE RECORD <SFI to EF_VALUE by DF_A, “00 ... 00”>

b.After successful entry into the EFs, the service terminal causes the VAS request record of EF_DIR to be deleted.

• SELECT FILE <AIDvas> (display error if VAS media is not selectable) • UPDATE RECORD <SFI of EF_DIR by DF_VAS, record number with FIDDF_A, “00 ... 00”, FIDDF_A>

PIXa was not interconnected with DF_A because of SELECT FILE with PIXA, which was not possible.

The following is the EFJTRANSFER implementation group:

Your R&R execution group EF_TRANSFER request can only be deleted at the express request of a cardholder from a dealer or service terminal (sometimes it is thought that this could be technically possible in both cases) . Deleting a task from EF_TRANSFER becomes necessary, in particular, if the memory for storage has no more space (free space) to store a new task (ie payment document or receipt). Deletion is always done indirectly (indirectly) with the additional command YES. This command only marks the task as in the transfer. Only then is it free to move on through the next additional TRANSFER command. Deleting this VAS request proceeds as follows:

1. The card holder places the VAS card in a terminal capable of displaying the contents of EF_TRANSFER (special case of a VAS request operation).

2. The terminal checks (searches for) where your VAS is located:

• SELECT FILE <AIDvas> (display error if VAS media is not selectable) • READ RECORD <SFI on EFJD, 0> (VAS media ID is displayed)

3. The terminal shall make it possible for the cardholder to choose from several options. One of them reads like deleting a VAS request. Choose from the cardholder. Finally, the VAS requests from the execution group5 we EF_TRANSFER are now displayed on the card holder display and a selection is made. This is considered as a special case of the operation displaying your VAS requests. The cardholder selects a task from the enforcement team that includes a payment document or receipt. This task has an entry number A. The card holder activates the selection.

4. The terminal marks the entry with record number A, upon transfer of which A is transmitted, a random number calculated by it, its PIX and the terminal ID, using the command:

• YES <A, random number, PIX terminal ID>

The entry is marked as having been transferred, now the place is available again to accept a new payment document or receipt.

The VAS request is selected as follows:

If a VAS request A from the execution group DF_PT or DF_AD was introduced into the VAS medium by the operation of entering a VAS request, this can be done from a terminal in two steps. First the VAS medium is selected and then the VAS request including its PIXA:

1. SELECT FILE <AIDVAS> (display error if VAS media is not selectable)

The service terminal needs to verify the authenticity of the VAS media. For this purpose, the service terminal requests (verifies) the internal authenticity of the VAS media:

• READ RECORD <SFI on EFJD, 0> (media displays on the display) • INTERNAL AUTHENTICATE, random number, KID from KAUT>

The service terminal checks compliance and interrupts the operation in case of error (with display error).

2. SELECT FILE <PIXa> (display error if VAS request A was not entered into VAS media)

A dealer terminal (which does not have a valid KGKAUT) may indirectly determine the authenticity of the VAS medium by verifying the authenticity of the VAS request A. This is because the VAS request can only be entered by a service terminal that during the induction procedure the authenticity of your VAS media. Authentication verified for VAS request A may be re-tested by the dealer terminal when the VAS carrier contains Klvasp or KRVASP for VAS request A. This can be verified through the dealer terminal, for example as follows:

• INTERNAL AUTHENTICATE <random number, Kvas of Krvasp or Klvasp>

In the case of a test where VAS request A is entered into the VAS carrier, it may be selected at random; based on the error on the display in the corresponding SELECT FILE message, the decision may be made to fail.

Selection of a VAS request from the execution group EF_TRANSFER is carried out unconditionally through the operation of displaying VAS requests and information memory of the terminal. Once the terminal knows the record number of each query displayed by EF_TRANSFER, it is possible to select which desired query for further processing with reference to the record number.

The execution of displaying your VAS request is as follows:

The operation of displaying VAS requests differentiates (sorts) the screen of the service terminal a list of all VAS requests from the execution group DF_PT, DF_AD and EF_TRANSFER. Only the VAS request from the EF_TRANSFER execution group can be displayed on the dealer terminal display because there is no security for such access, and optional also for requests from the DF_PT or DF_AD execution groups for which the dealer terminal is allowed to read ( owns Krvasp).

All this for your VAS request is done as follows:

1. The card holder shall place the VAS card in the terminal.

2. The service terminal looks for where your VAS is located:

• SELECT FILE <AIDvas> (display error when VAS media is not selectable) • READ RECORD <SFI on EF_ID, 0> (VAS media ID is displayed)

Optional validity of VAS media is checked. For this purpose, the service terminal requests (verifies) the internal authenticity of the VAS media:

• INTERNAL AUTHENTICATE <random number, KID from KAUT>

The service terminal checks compliance and in the event of an error (with a display error) interrupts the procedure.

3. The service terminal presents the cardholder with a choice of several options. One of them reads displaying your VAS requests. This is chosen by the cardholder.

4. The service terminal shall authenticate:

• GET CHALLENGE • EXTERNAL AUTHENTICATE <KSO (random number), KID by KSO>

5. For VAS requests from the DF_PT and DF_AD runtime groups, separate VAS requests that are sequentially processed by the contents of EF_DIR and, after establishing external authentication with the KSO key, the contents of the individual EF_INFO (or part thereof according to R&R), and EF_VALUE are displayed:

• For i = 0, ..., nrDIR - 1 • READ RECORD, SFI on EF_DIR, I>

The response message on the display shows PIXA, which is "00 ... 00" if the corresponding DF is not entered with your VAS request. Alternatively to the READ RECORD of EF_DIR it is also possible to use the SEEK command.

• If PIXa is not equal to “00 ... 00” • SELECT FILE <PIXa>

• READ RECORD <SFI on EFJNFO, 0>

• Display (optional, only partially) of the reply message • READ RECORD <SFI on EF_VALUE, 0>

• SELECT FILE <AIDVAS>

6. 3a VAS requests from the performance group EF_TRANSFER the contents (or parts thereof according to R&R) of EF_TRANSFER from each entry are displayed:

• SELECT FILE <AIDVAS>

• If i = 0, ..., nrEF_TRANSFER -1

READ RECORD <SFI on EF_TRANSFER, i>

(the reply message shows the contents of the i-record from EF_TRANSFER) • If the contents are not complete, they are displayed on the display in processed form (eg 5 displayed / deleted).

The display of requests from the DF_PT or DF_AD execution groups for which the dealer terminal is authorized to display (owns Krvasp) is performed as a description, subject to two exchanges. For example, authentication with the Krvasp key is used instead of Kso, which is only valid for the system operator. If the dealer terminal does not have a valid KGKaut and nevertheless 15 wishes to verify the authenticity of your VAS requests, the dealer terminal instead of internal authentication can authenticate (at least one) to the VAS request. This is done as a description by recognizing the card from the respective Krvasp or Klvasp keys on the map.

For VAS requests from the EF_TRANSFER runtime group, the contents (or a portion of them according to R&R) of the EF_TRANSFER of 25 each list were sorted (sorted, expanded) sequentially in a list as previously described.

The VAS request processing operation is as follows. For this purpose, the Terminal 30 offers the cardholder the ability to process VAS selection requests. In addition to the information that begins to appear on the display, respectively of the display operation, it is also possible to display on the display information from EF_INFO and EF_VALUE that require processing by the VAS contractor, such as externally encoded information, and information from EF_TRANSFER, for example, foods from the previous 40 years with Food & Other. This is sometimes only possible for VAS requests, for which the VAS contractor (in terms of its own capabilities) makes the corresponding terminal keys possible. The 45 Klvasp key (external authentication) is used to read the EF_INTERNAL of your VAS request. For externally encoded information in the EF_INFO, EF_INTERNAL and EF_VALUE Elementary Files, as well as in the exchange memory 50 EF_TRANSFER, the VAS executor's own keys are used. are available for processing information.

The VAS request exchange operation refers to the exchange of all or selected VAS requests from the contents of the card into the card itself placed in the service terminal. It can be concluded that not all VAS requests are entered in the VAS card carrier itself and that after the exchange all VAS requests are deleted from the contents of the card. Both cases can be accompanied by successive applications of the delete VAS request operation. Moreover, the authenticity of the VAS card must be verified and the card itself must be adequately filled with the amount of memory. The exchange operation itself is based mainly on extending the operation of displaying VAS requests, for which the information from EF_INTERNAL and the Klvasp and Krvasp keys is additionally read and based on the operation of entering a VAS request.

Along with the VAS information, the VAS carrier, of course, exchanges for the card in succession the VAS requests from the card itself for immediate execution, just as they are recorded on the card. The rules by which these keys are created by the VAS contractor are stored by the VAS media ID, with the keys sometimes repeated unchanged. Moreover, the VAS contractor does not intend to change its calculation in the base system, because it usually identifies VAS cards through the VAS media ID. It is essential to ensure that during the exchange of VAS media the number (which is unique) for the system is deleted from the contents of the card.

In order to be able to specifically read the EF_INTERNAL elementary file and the Klvasp and Krvasp keys, the service terminal after authentication by means of the Kso key (as in a VAS request deletion operation) first overwrites the Klvasp key and then after the authentication is restored with Klvasp overwrites the information from EF_INTERNAL.

In addition to the VAS requests from the DF_PT and DF_AD execution groups, the EF_TRANSFER file must be overwritten. For this purpose, the move (transfer) operation is used sequentially to transfer tasks from this execution group that have not yet been marked as transferred or deleted (disappeared), check their signature via KSIG_VASC, and exchange at EFJTRANSFER the map itself. In the card itself, on the other hand, the tasks are marked as unassigned so that they remain valid (valid).

Finally, the publicly available information on the VAS medium must be exchanged. In particular, the serial number from the card itself must be added to the values from the contents of the card.

The procedure for entering VAS information is described as follows:

There are three possible cases for entering VAS information from a dealer terminal that relate to the nature of your VAS request.

First, purchase in the case of DF_PT or DF_AD.

The VAS contractor enters information into VAS request A from the DF_PT or DF_AD execution group.

Entering your VAS information is as follows:

1. The card holder places the VAS card in a dealer terminal.

2. The dealer terminal checks the location of your VAS:

• SELECT FILE <AIDvas> (display error if VAS media is not selectable) • READ RECORD <SFI on EF_ID, 0> (display on VAS media ID)

3. Verify the authenticity of your VAS media.

If the dealer terminal has the KGKaut master key, it can establish the external authentication of the VAS media:

• INTERNAL AUTHENTICATE <random number, Kaut by Kaut>

A dealer terminal (not KGKaut-enabled) may indirectly (indirectly) authenticate the VAS media by verifying the authenticity of your VAS request A. The rules are such that a VAS request can only be entered by a service terminal, which during the the introduction verifies the authenticity of your VAS media. Authentication verified for VAS request A can be referred back to the dealer terminal test, where the VAS carrier holds the Klvasp key or the Krvasp key for VAS request A. This can be verified through the dealer terminal, for example by:

• SELECT FILE <PIXa> (display error if VAS request A is not entered in VAShoot ^ r) • INTERNAL AUTHENTICATE <random number, Kvas from Krvasp or Klvasp>

The dealer terminal checks compliance and in the event of an error (with a display error) interrupts the procedure.

4. The dealer terminal selects VAS request A, verifies it for authenticity and describes the Elementary files that are required to complete the transaction:

• SELECT FILE <PIXA> (frustrated if this is done in step 3) • GET CHALLENGE • EXTERNAL AUTHENTICATE, Klvasp (random number, Kvas from Klvasp>

• Optional: UPDATE RECORD <SFJ of EFJNFO from DF_X, data>

Optional: UPDATE RECORD <EFI of EF_INTRNAL of DF_X Data>

Optional: UPDATE RECORD <SFI on EF_VALUE of DF_X data>

Purchase now in case of performance group EF_TRANSFER.

Specifically for VAS requests from Execute Group EF_TRANSFER (request group Payment Document), the VAS contractor does not need to have its own DF_X structure file for its request. The answer is that the cardholder does not need to go to a service terminal to enter your VAS request before using a payment document from your VAS request. Rather, it may, directly from a dealer terminal, enter a payment document or receipt and make these payments from another terminal (through the transfer operation), or only show the payment document or receipt (by reading). Entering VAS information is the answer to the unconditional entry of VAS requests in the execution group EF_TRANSFER. For this query group, the execution group EF_TRANSFER checks what is assigned to the individual tasks in the record. Access to EF_TRANSFER is possible exclusively through the TRANSFER command. For this purpose, the dealer terminal must have a valid cancellation key

KDEC and PIXA of your VAS request A must be available.

Entering your VAS information is as follows:

1. The card holder places the VAS card in the dealer terminal.

2. The dealer terminal checks the location of your VAS:

• SELECT FILE <AIDvas> (display error if VAS media is not selectable) • READ RECORD <SFI on EF_ID, 0> (the display shows the VAS media number

3. The dealer terminal reads the serial number, which further introduces the MAC from step 4:

• READ RECORD <SFI of EF_SEQ, 0> (the serial number is displayed)

4. The TRANSFER command causes an entry to be entered in EF_TRANSFER:

• TRANSFER <transaction data, missing data, creation code, data, PIXa, MAC with Kdec>

5. The dealer terminal may verify by verifying the response message from the TRANSFER command that your VAS bearer is authentic (ie in possession of the Kdec mutual secret). In this context, a choice, also made in the response message following the TRANSFER command, is described above.

Finally, purchase VAS information by canceling values.

A VAS contractor can, through a value cancellation step using the TRANSFER command in the EF_TRANSFER exchange area, create a right (such as a payment document or receipt) that can be used later by another VAS contractor. The information from EF_VALUE or EF_INFO of VAS request A is canceled by the VAS contractor causing the cancellation. The card holder acquires his right in the form of a task in EF_TRANSFER.

Entering your VAS information is as follows:

1. The card holder places the card in the dealer terminal.

2. The dealer terminal checks the location of your VAS:

• SELECT FILE <AIDvas> (display error if VAS media is not selectable) • READ RECORD <SFI on EF_ID, 0> (VAS media ID is displayed)

3. The dealer terminal reads the serial number which, in addition, it enters

MAC as in Step 4:

• READ RECORD <SFI of EF_SEQ, 0> (the serial number is displayed)

4. The dealer terminal selects VAS for 10th A:

• SELECT FILE <PIXa> (display error if VAS request A was not entered into VAS media)

5. The dealer terminal uses the TRANSFER command to cancel information from EF_VALUE or EF_INFO, in which case the following may be the case:

• TRANSFER <data, MAC with KDEC>

The combination of the TRANSFER command message has already been described. The right to execute a cancellation is invoked by the terminal if it can form a true signature containing information about KDEC funds. This signature is verified by the VAS medium and the serial number increases.

6. The dealer terminal may verify by verifying the TRANSFER command message that your VAS bearer is authentic (ie in possession of the known Kdec secret).

The procedure for canceling VAS information is as follows. There are two cases of cancellation procedures:

On the one hand, your VAS information about

VAS requests from the DFJPT or DF_AD execution group can be canceled by the authorized VAS contractor through the cancellation operation, i.e. purchase of VAS information by cancellation. In this way, monetary values are consumed, thus creating a potential entitlement to different values.

On the other hand, the VAS information can only be displayed by EF_TRANSFER once through the optional YES command. In this instance, the right is consumed, the information remains available for further use (eg the refunded ticket is 50 just used for a return trip) in the exchange area, it is marked as having been transferred until it is searched for other tasks in the performance them.

The cancellation of your VAS information via the following command is as follows:

1. The card holder places the card in the dealer terminal.

2. The dealer terminal checks where your VAS carrier is available:

• SELECT FILE <AIDvas> (display error if VAS media is not selectable) • READ RECORD <SFI by EF_ID, 0> (VAS media ID is displayed)

3. The dealer terminal first displays on the display the tasks of EF_TRANSFER that are available, using the special case of the operation of displaying VAS requests to decide where task execution is possible. Conversely, the SEEK command can only be applied to search. If the terminal has succeeded, it knows the i number of the search entry.

4. The terminal marks the record to display the record number i for which it transmits i, the random number calculated by it, its PIX and the terminal ID with the command ALSO:

• IS <i, random number, PIX, terminal ID>

The dealer terminal uses the YES command to read information from EF_TRANSFER, approximately identifying the information as having been downloaded. The execution of the command, in addition, is considered to create two different cryptograms C1 and C2.

The C1 cryptogram is calculated from the VAS medium using the Ksig_vasc key. Thus, the result of the assignment of the task marked with C1 can obtain proof of uniqueness (one path) and authenticity from the system operator. The uniqueness and authenticity of the transaction stems from the cryptogram of the VAS contractor, from which the task was originally initialized (and verified by the card, see also TRANSFER), and from maintaining the random count of the transactions, as well as the C1 cryptogram through the card during the download.

The C2 cryptogram is computed from the VAS medium using the KGKdec key created by the VAS medium from KGKDEC, PIX and the ID terminal. For the knowledge of the Kdec mutual secret, the VAS medium can directly confirm at the terminal the authenticity of the VAS medium. Considering that during the TRANSFER command the check was made, and also that only authentic payment documents or receipts were installed in the authentic VAS medium, then the authenticity of the downloaded task can be considered convincing. After C2 is indirectly formed (indirectly) by the sequence number, the downloaded bit and the VAS media ID, the VAS media can sometimes check the uniqueness terminal (one path) for the downloaded task.

Everyone has the right to download using the YES command.

In addition, deactivation or activation, respectively of the password or PIN security for reading VAS requests from the DF_PT and DF_AD execution groups is possible from the service terminal. In addition, the PIN of the VAS media can be changed by the cardholder knowing the PIN and can be renewed by the system operator through the means of external authentication through the KSO.

Non-numbered characters or a sequential character from a known sequence can also be used as a PIN or password.

Claims (34)

Claims 1. A transaction card in which cash or other value data representing non-monetary rights is exchanged between the cardholder, and in particular one transaction partner (service provider) or is presented to the service provider for certification of rights, wherein the chip card contains a memory that stores the necessary information for the transactions and the chip card is characterized by the following: means for entering one or more card requests (VAS requests) graduations known service provider, respectively. on the card, each requesting the ability to transact between the cardholder and the service provider designated by the request; an exchange memory area (EF_TRANSFER) that does not belong to the storage service provider, which exchanges or is shown to each other in the execution of the transaction between the different service providers33, and which represent cash or non-monetary rights; and a means of recording information (data) in the memory by the operation of a recording command (TRANSFER), 2. The chip card according to claim 1, wherein the input means comprises: information structure (DF_VAS, VAS media) stored in which contains: a separate structure (DF_PT, DF_AD, VAS request), in which the necessary data (VAS data) can be entered in order to carry out the possible execution of a transaction between the cardholder and the service provider; a definitive information network that stores information regarding the nature and / or structure of the stored data in a separate structure (VAS request); and where the definitive information network further comprises: a master attribute (media-ID) that identifies the information structure (VAS media) and / or the chip card; and an additional key system (Kso) that protects the integrity of the Definition Information Network and / or Information Structure (VAS) against modifications. Chipcard according to claim 2, characterized in that it contains at least one of the following features: means for entering the data necessary to execute transactions in the individual structure using at least one system key; means for recording data in the Definition Information Network for applying data from the Definition Information Network to the data entered in the separate structure; means for creating an additional separate structure in which the necessary execution information can be entered into the card database; and / or a dynamic administration tool in the memory of the card. Chipcard according to claim 2, characterized in that the individual structures (VAS requests) are represented by interdependent separate structures, each pre-designated as an independent service provider; the definition information network 5 is protected against modification by at least one system key (KSO) and can only be modified by the means of that key; and that the introduction to individual structures (VAS requests) can only continue with the system key stored in the information definition network. Chipcard according to claim 2, characterized in that the definitive information network contains at least one of the following features: at least one key for establishing the authenticity of the chip card with respect to the terminal and / or the authenticity of the right of the terminal with respect to the chip card; at least one signature key (Ksig_vasc) to indicate downloaded data from the memory for exchange; key-generating key (KGKdec) for an operating terminal and specific request request keys to verify the right to write to the exchange memory and / or to cancel monetary value information; PIN to verify the right to the transaction procedure by the cardholder; The system key (Kso), authentication key (Kaut), signature key (Ksig_vasc) and key-generating key (KGKdec) are either individual card keys or information structure specific (DF_VAS); and the separate structure (VAS request) contains at least one of the following features: at least one cash memory (EF_VALUE) for storing cash information; at least one internal memory (EF_INTERNAL) for storing inside information pertaining to the individual structure; at least one information memory (EF_INFO) for storing inside information pertaining to the individual structure; key memory (EF_KEY) for storing at least one key (Klvasp, Krvasp) which provides write protection and / or a procedure for retrieving data in or from the monetary memory and / or internal memory, and / or the information database. In addition, the chip card further includes: means for recording and / or retrieving data in or from monetary memory, internal memory, or database, and the input means include: a key recorder in a key memory protected by at least one system key. Chipcard according to claim 2, characterized in that the individual structure comprises at least one of the following integral parts: a key (Klvasp) for checking the right to write data in a separate structure; key (Krvasp) for checking the right to find data in a separate structure. Chipcard according to claim 2, characterized in that the keys stored in the key memory are specific to the respective separate structure, with at least one separate structure (VAS request) protecting the execution of transactions by the means of at least one from specific keys (Klvasp, Krvasp), which is specific to the individual structure (VAS request) and is independent of the keys to the other individual structures (VAS requests). Chipcard according to claim 2, characterized in that the card comprises a plurality of separate entities (VAS requests), each of which serves to execute transactions between an individual service provider and a cardholder, the execution of the transactions including a record and / or finding data in or from the field of exchange and / or recording, and / or finding data in, respectively. from memory for monetary values. Chipcard according to claim 2, further comprising: a means of executing transactions, both between individual individual entities (VAS requests) and between an individual entity and a service provider. Chipcard according to claim 2, characterized in that the system key (Kso) is known only by the system operator (SO) and is an individual card key and / or information-specific structure (VAS carrier), such as the keys stored of the Definition Information Network are individual card keys and / or information structure specific (VAS media). Chipcard according to claim 2, characterized in that the definition information network comprises one or more of the following integral parts: Identification number (EF_ID) specific to the information structure; structure-specific directory address (EF_DIR) stored in the information structure, the structure-specific address book (directory) containing specific structure-specific identification numbers (VAS requests) entered in the information structures (VAS media) as well as the stored information as part of an information structure (VAS medium) in which individual structures (VAS requests) are physically stored; variable information structure number (EF_VERSION). Chipart according to claim 2, characterized in that it comprises at least one of the following features: a means of performing a data download procedure (YES) through which the data can be transferred and / or value canceled from the memory to be exchanged; means for generating one or more indications of data authenticity while downloading or canceling data from an exchange memory. 13. A chip card according to claim 12, characterized in that the chip card comprises the following to create identity features: signature key (KSIG_VASC) for creating a digital signature for downloading data; means of generating a transaction number characterizing the transaction, which means is only used when creating a digital signature. Chipcard according to claim 13, characterized in that the signature key (Ksig_vasc) is an own key created by a private key to create keys and that common keys are used to verify the signature by the service provider. Chipcard according to claim 14, characterized in that it comprises at least one of the following integral parts: a key-specific key creation tool (Kdec) for terminals and individual structures by means of a key-generating key (KGKdec); a means of verifying the right and / or protection of a transaction by using at least one of the following integral parts: • a specific key (Kdec) for a terminal and a separate structure, • at least one authentication key (Kaut), • at least one system key (Kso), • at least one specific key (Klvasp, Krvasp) for a separate structure , • signature key (Ksig_vasc), • PIN, • individual structure identifier, • terminal identifier. Chipcard according to claim 5, characterized in that it comprises at least one of the following integral parts: means for authenticating a right and / or terminal by means of an authentication key prior to initiating a process for finding or recording data; means of performing procedures for finding or recording data that is protected by digital signatures and / or a key. Chipcard according to claim 16, further comprising at least one of the following integral parts: means for activating and deactivating PIN protection; a means of changing the PIN. 18. The chip card according to claim 2, characterized in that the information structure according to claim 2 is independent of the card board, and the chip card further includes means for exchanging the information structure or parts of the information structure with another card. 19. The chip card according to claim 2, characterized in that it comprises the following: an area of memory held by the service provider for recording or retrieving data in or from the memory area from different providers of money exchange services and / or valuable information representing other non-monetary rights between different service providers. 20. A chip card use terminal according to claim 2, characterized in that it comprises: means for identifying an information structure (VAS carrier) of the chip card, and for identifying a feature (carrier-ID) identifying the information structure; the terminal further comprising at least one of the following features: means for recovering data from at least one of the individual structures and / or the definitive information network and / or the memory for card exchange; means for storing data in the memory for card exchange; a means of entering the data necessary to execute the transactions in at least one of the individual entities (VAS requests) on the card. A terminal according to claim 20, characterized in that it comprises at least one of the following integral parts: means for executing transactions between the service provider and the cardholder, the execution of a transaction comprising at least one of the following steps: storing data in memory for monetary values; recording of data in the memory for exchange; transfer and / or cancellation of data from the memory for exchange; finding data in a separate structure; finding data in the memory for sharing. A terminal according to claim 21, further comprising: means of verifying the right to and / or protection of a transaction by means of at least one of the following integral parts: terminal-specific and separate structure-specific key (KDEC) at least one authentication key (Kaut) that is card-specific or information-specific (DF_VAS); at least one system key (Kso) that is individual to the card or specific to the information structure (DF_VAS); at least one specific key for the individual structure (Klvasp, Krvasp); at least one signature key (Ksig_vasc) that is individual to the card or specific to the information structure (DF_VAS); PIN that is individual to the card or specific to the DFVAS information structure); a specific feature of the individual structure in terms of the application; a specific characteristic of the terminal in terms of the terminal. A terminal according to claim 22, characterized in that the data storage medium in the exchange memory comprises: a data encoder using a terminal and a Kdec specific key to confirm write rights. A terminal according to claim 20, further comprising: a means of executing the process of retrieving data from an exchange memory through which the data are transferred from the exchange memory and / or are canceled. The terminal of claim 24, further comprising at least one of the following integral parts: means for characterizing the information in the exchange memory when transferred; means for characterizing information in the memory for exchange when it is lost (lost). 26. The terminal of claim 20, wherein the transaction execution agent comprises at least one of the following integral parts: a means of changing the value data in the individual structure; a means of transacting between different service providers (mutual services) to spend the account, and instead of the card holder. 27. The terminal of claim 20, further comprising: means of authenticating the right from the card-relevant terminal and / or from the card corresponding to the terminal using at least one authentication key; a means of protecting a transaction from a cardholder by means of a PIN; means of activating and deactivating PIN protection. The terminal of claim 20, further comprising at least one of the following integral parts: means for exchanging a terminal specific feature for the card; means for exchanging the specific characteristics of the individual structure for the card; means for establishing the authenticity of the right to use a specific terminal key and a separate structure, as well as the specific characteristics of the terminal and the individual structure; means for performing data retrieval or data recording procedures that are protected by digital signature and / or encryption. The terminal of claim 20, further comprising at least one of the following integral parts: separate structure selection tool (VAS request); means for displaying a separate structure of the terminal display; means for displaying the data of the individual display structure of the terminal; means for inserting the individual structure (VAS request) into the card; means for inputting the characteristic to the entered separate structure (VAS request) in the card; means for clearing the individual structure of the card; a means of replacing a single structure37 with different individual structures; means for exchanging (transferring) an individual structure to another card; a means of processing the individual structure in terms of its functionality and its associated service provider, as well as finding data and displaying the information stored therein. 30. A method of conducting transactions between a cardholder and at least one service provider involved using a chip card and a terminal, the method comprising at least one of the following steps: creation of a storage (memorable) information structure in the chip card in which request data suitable for a service provider can be entered for a possible transaction between the cardholder and the so-called service provider (VAS information); as well as recording in / or reading data from the information structure (VAS request) for transactions between the cardholder and the so-called service provider; creation of a non-service provider non-performing exchange memory area (EF_TRANSFER) to store monetary value information representing non-monetary rights to be exchanged or presented during the transaction between different service providers; as well as storing information in the memory for sharing or finding information in the memory for sharing. The method of claim 30, wherein the method comprises at least one of the following steps: use of the chip card according to claim 1; use of a terminal according to claim 20; recording or retrieving data in or out of value memory or external memory, or information memory of at least one of the individual structures (VAS requests). 32. The method of claim 31, further comprising at least one of the following steps: authentication of a right from a terminal and / or via a chip card using at least one key; secure the transaction by using a digital signature and / or encryption using at least one key. 33. A method for entering data into a chip card using a terminal, characterized in that the method comprises at least one of the following steps: entering data into the separate structure (VAS request) on the card; recording data in the card definition information network, the method further comprising at least one of the following steps: using the chip card of claim 1; use of a terminal according to claim 20. 34. A transaction system characterized by the use of a chip card according to claim 1 and a terminal according to claim 20. Attachment: 10 figures