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

Abstract

The invention relates to a chip card for carrying out transactions in which value data representing units of monetary value or other, non-monetary entitlements is transferred between the card holder and at least one transaction partner (service provider) or is presented to the service provider for verification of such entitlements. The chip card is characterized in that it comprises a memory in which the data required for carrying out the transactions is stored, and in that it has a device for loading the card with one or more card applications (VAS applications), which in each case permit transactions to be carried out between the cardholder and one or more service providers.

Description

Smart card and how to use smart card

Technical field

The invention relates to a smart card, a terminal for use with a smart card, a method of using a smart card and a smart card system.

Microprocessor chip cards with payment function, e.g. for electronic money exchanges, ec-cach, credit function, etc. they are already in use and, depending on the edition of organizations such as ZKA (Zentraler Kreditausschuss), VISA or EMV (Europay Mastercard VISA), they have advantages and can be used as means of payment (“money refund”). Examples include:

ZKA, Zentraler Kreditausschuss, „Schnittstellen - Specification of the für die ecKarte mit Chip 27.10.1995;

Europay International, "Integrated Circuit Card, Spacification for Payment System, EMV '96", V3.0, 30-Jun-1996;

ISO / IEC 7816-4, "Information technology - Identification cards - and Circuit (s) cards with contacts, Part 4: Interindustry commands for interchange", 01-9-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: Security architecture” 03.07.1995;

prEN 1546-3, “Identification card systems - Inter sector electronic purse, Part 3: Data elements and interchanges”, 09.12.1994;

Current overview of smart cards can be found in:

Stefan Schiitt, Bert Kohlgraf: “Chipkarten, Technische Merkmale, Normung, Einsatgebiete”, R. Oldenburg Verlag, Munich - Wien, 1996, ISBN 3-48623738-1.

Traditional smart cards are regularly usable only for one purpose, for example for an electronic money exchange or as an electronic card. However, the applications applied to these smart cards are periodically static, i. they are applied in the production of the smart card and remain unchanged throughout the cycle of use of the card.

Traditional chip cards are therefore limited in terms of both variability and functionality. In particular, traditional chip cards are firmly established and immutable after the manufacturing process in terms of their functionality.

It is therefore an object of the present invention to provide a smart card whose functionality is variable.

Another object of the invention is to provide a smart card in which the number and type of applications, respectively. The use and transactions possible with the smart card are variable even after the manufacturing process. It should be possible to "charge" additional applications to this smart card; the applications should be deleted from the smart card, and the individual applications should be independently defined in terms of data and technical security and independently of each other.

For example, the smart card should meet the data and security requirements of ISO 7816; however, the individual applications of the card should be primarily independent of the card base itself.

A further object of the invention is to provide a smart card in which the user can change or change the chip card. to compile the number and type of applications his card has. Furthermore, it is an object of the present invention to provide a smart card with which they can be performed both as internal services (ie closed applications in the sense that there is no billing and performance transfer with external partners) as well as external services (ie applications with additional external relationships to external partners ).

According to one aspect of the invention, there is provided a device by which one or more card applications can be charged to enable transactions between the card owner and one or more service providers to be executed.

By charging, the smart card is configured to receive new functionality, i. can make an app that it hasn't been able to do before. With the charged data, the applications are defined and, in conjunction with the card's basic functions such as the operating system, those applications that were not previously available on the card are implemented. This will extend the functionality of the card by charging an application with this application.

According to an embodiment of the invention, a data structure (DF-VAS) is formed on the chip card according to the invention, which itself is again divided into a sub-structure and a definition data file, the data structure being unambiguously identified by means of the identifier identifying it and thereby independent of base card. The sub-structure can now be charged to the so-called. applications, i. functionality or ways of using a smart card. This will allow the application to charge transactions between the card owner and the application-specific service provider. The definition data file within the data structure contains information about the type and / or structure of the applications loaded in the sub-structure. At least the definition data set, but in particular the entire data structure, is insured against modification by at least one system key and modifiable only by the use of that key. Instead of a system key, other locking mechanisms or locking devices are also conceivable by means of which it is possible to secure against modifications, for example by means of a personal tag (PIN) or other locking devices. With the above-mentioned structure, it is possible to charge various applications into the sub-structure and to delete them again from the sub-structure, so that the card is, due to its functions, resp. to applications with it, variable. Charging and deleting by application is done by writing application-specific data and keys into the current sub-structure. By introducing the system key and the data structure feature, the data structure, allowing for a variety of functions, is independent of the card base itself, but also with respect to its self-supporting and card base independent security architecture.

Depending on the partial structure of the charged applications, the card can then execute transactions based on the charged applications between the card owner and the service provider.

In particular, the smart card further has a conversion memory unit into which it is written in and from which transactions are executed. the exchanged data is read. While terminal-specific keys are used to extract data from the conversion storage unit, the individual approaches are technically independent of each other.

Individual sub-structures, resp. the applications available in the card are particularly independent of each other and assigned to a particular service provider. Thus, they represent, for the service provider, their own and specific data for the execution of one particular application. They therefore contain different information, depending on the type of application and each service provider, for example data representing one particular value (bonus points, account-state, etc.), application information, service provider information, etc. In particular, however, they also contain, in particular, application-specific keys, by means of which access to the data of the sub-structure is made possible in a manner technically independent of other structures. Charging and generating the sub-structure, resp. the application itself, on the other hand, is provided by at least one parent system key.

Especially before the transaction is executed, mutual access authorization between the smart card and the terminal is verified, using the application and / or the application. Partial structure-specific, verification key.

In order to execute the transactions, data is then written to or read with the partial structure reserved for the respective VAS application or derived by means of a conversion storage unit. In the first case, application-specific keys are used. In the latter case, an application-specific and in particular also a terminal-specific key is used, which, for example, is provided by a key-production key available on the card and generated from application-specific data. The data thus written to the read-out memory may then be read into the service provider by the terminal, which in particular becomes marked as spoiled by the mark in the read-write memory. If it is a service provider that is not specific to the writing application, this is done by the so-called. intermediate service, i. they will be exchanged in favor or at the cardholder's expense, monetary value data between different service providers. In addition, a PIN or password is provided to verify the eligibility of the transaction process.

By varying the card structure, different applications in different numbers can be stored on the card at different times.

The authenticity of the data read from the transfer memory is ensured in particular by the use of a signing key, or by the use of a digital signature or at least one key. It is particularly advantageous here that the read data remain in the transfer memory, but only if they are marked as read by the card. This can also be used to obtain information about the transaction after the transaction. This and the deduction is also a proven uniqueness (repeatability).

Furthermore, it is particularly advantageous if the data written to the transfer memory is indicated by the overflow date after which it loses its value. This makes feasible applications which, for example, allow a ticket to be available for a certain period of time.

In particular, the transaction data used can be unambiguously determined and identified using the transaction counter used, respectively. value data with respect to their respective transactions.

in

The chip card, in a preferred embodiment according to the invention, is based on a hierarchical concept which is secured on its different planes against modifications by means of different keys, which is variable on the application plane with respect to the memory-loaded applications. and the entire structure is provided by at least one system key and a feature identifying the structure and is independent of the card base itself. The transfer memory concept enables data exchange, both between the card owner and the service provider, as well as between the different service providers themselves. Also, reading from and writing to the read-only memory is provided by a key, and these actions are also card-specific and application-specific, but also terminal-specific. Access authentication that is performed prior to each transaction and the option of selecting a PIN or password additionally increases the security of the smart card of the invention.

Claims 21 to 30 define a terminal for use with a smart card according to the invention. This terminal is used to charge or delete applications, execute transactions, view data, and execute other applications in conjunction with current applications and fixed function transactions. A method of executing transactions between the card owner and the service provider is defined in claims 31 to 33, charging the data to the smart card according to the invention is defined by claims 34 and 35, and claim 36 defines the entire system from the smart card and terminal.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, the invention will be described in more detail according to a preferred embodiment with reference to the accompanying drawings.

Fig. 1 shows a chip card according to the invention schematically; FIG. 2 is a schematic representation of the entire system of components of the invention; FIG. 3 shows a data flow throughout the system, FIG. 4 is a schematic representation of possible application classes and transaction model operations; FIG. 5 is a schematic representation of the security architecture of a smart card according to the invention, FIG. 6 shows a data structure of a general implementation class of a VAS container; FIG. 7 shows various implementation classes of a VAS Container according to an exemplary embodiment of the present invention; FIG. Fig. 8 is a data structure of a VAS Container according to an exemplary embodiment of the present invention; 9 schematically: data structure of the DF-PT implementation class; FIG. 10 schematically: DF-AD implementation class data structure.

Before describing the invention in more detail, several terms will be defined below:

VAS: Value Added Services

VAS Card: A VAS card is a smart card with which Value Added Services can be shared. The VAS card contains, among other uses, such as: payment applications (ie electronic money exchanges) container VAS.

VAS-Container: The VAS container contains data structures, access conditions, keys, and (by-pass) commands for managing VAS applications and preparing VAS application functionality.

VAS Applications: VAS applications contain VAS data. Access to VAS data is controlled by the VAS application. The VAS-Provider executes one or more VAS applications in a VAS container. The use of the VAS application is defined from the storage, reading and processing of VAS data. The VAS application can be either intra- or interservice.

VAS Provider: The VAS supplier is responsible for its VAS applications, which it unwinds according to the system operator's framework conditions and according to its own ideas and then prepares through the system operator and the Cardholders terminals for use. VAS applications are charged to the VAS container by the VAS cards before they participate.

Intraservice: Intraservice is a type of VAS application that is used under the exclusive overhead of the relevant VAS provider (“supplier”). Intraser visu applications are closed applications in the sense that there is no charging or performance transfer with external partners. VAS applications can be either intra- or interservice.

Interservices: Interservice applications are intraservice applications that reach out to external partners through additional external relationships.

SO, System Operator: The system operator or system operator offers VAS vendors and cardholders - cardholders - to use the VAS system.

Issuer: The issuer or card issuer is the person who owns the card (here: VAS card) and puts it into use to participate in Value Added Services. This person is not necessarily the cardholder.

Serviceterminal: The service terminal is set by the service operator for VAS applications. At the service terminal, the card owner can handle VAS applications on his VAS card (charging, browsing, deleting, and transferring VAS applications).

Trading terminal: The trading terminal contains payment functions and additionally offers VAS functionality. The card is inserted into the card by the owner in order to pay and participate in the benefits of the VAS.

AID: (Application Identifier) A maximum of 16 bytes long application names to uniquely identify and select applications from outside without knowing the card's data structure. AID consists of 5 bytes of long Registered Application Provider ID (RID) and a selected, maximum 11 bytes of Proprietary Application Identifier Registration (PIX) long.

DF: Directory Fillets according to ISO 7816

EF: Elementary Fillet according to ISO 7816

Valid VAS Container: A VAS Container that can be verified against the outside world.

KID: (Key Identifier) the key number within the elementary file that contains the key.

R&R: Rules and Regulations p: Maximum number of objects of implementation class DF - PT a: Maximum number of objects of implementation class DF ~ AD nroiR: maximum total number of objects: nroiR = p + a

Number of Records in EF - DIR is nroíR.

Nief- transfer? Number of Records of EF - TRANSFER

Fig. 1 schematically shows the structure of a smart card according to the invention. In addition to the static and unchangeable data production process such as the Masterfile and (optionally available) DF-Stock Exchange function, a list or list is available on the card according to the invention. DF-VAS data structure or Datein structure. This is used to receive additional functionality, the so-called Value Added Services VAS. Based on these additional features, applications that can be recharged to the card at a later point in time, ie after the card is manufactured, are flexible and variable due to their functionality and the transactions that can be performed with it. The so-called VAS container (DF-VAS) available on the card according to the invention allows for the variability and flexibility of the smart card with respect to its functions and also releases security-based applications technically from the card base so that they are card-independent and can even be transferred to another card.

New Value Added Services (VAS) are implemented by microprocessor chip cards. The implementation of these additional functions is carried out by a VAS container. The VAS container on the microprocessor or host card forms the basis for receiving VAS applications. VAS applications are relevant implementations of certain additional functionality. In the case of an electronic money exchange, card payment (payment functions) and the use of the VAS application (additional functionality) are based on separate mechanisms, from the perspective of the card user, respectively. card owner, but this may seem like one process.

The microprocessor chip card is extended with a VAS-Container, which can accommodate different and independent applications. He makes available functions for loading, deleting and transferring these applications; these may only be used by an authorized system operator. The VAS-Container is technically independent from other system components on the microprocessor chip for data and security. The VAS Container is fully self-defined and functionally capable. A security architecture is defined for it, so VAS applications use separate security features. The security architecture uses card-specific keys that are not production-specific and independent of card base identifiers.

VAS Container also uses mechanisms to derive terminal-specific keys. With these, the VAS-Container itself can actively test the authenticity of the terminals. data created by them.

In the VAS Container, the VAS applications are stored, which, via the VAS Container mechanisms, prepare data and thereby control the associated interfaces. VAS Container also enables and manages reliable data exchange for interservice between partners. The VAS-Container provides active control of the authenticity and uniqueness of the transmitted data values.

The advantage of the VAS Container over other multi-application card sets is that this concept is independent of a particular card base. She offers a security architecture that is independent of base-specific security mechanisms (such as keys, identification data, PIN, signature methods).

Another advantage of the VAS Container concept is that the number of different applications on the card is not predetermined by the constraints and advantages of the time of card production or card issuance; the current occupation of the card by means of use is freely selectable by the card user and is limited only by the available memory space on the respective card. The number of currently loaded VAS applications depends on the card's actual use. The card user builds the VAS applications individually on his card; this also includes changing the assembly to a later time point. The Container VAS allows a multifunctional card in which the card's lifecycle functionality can be built and used variable in number and type of use. Thus, they can be occupied and put into use by an application for which individual Special Cards have been needed to date on only one card. VAS applications can also be transferred to other cards. Thus, VAS applications can survive the life cycle of a single card; they accompany the card user during the life cycle of the uses.

An additional service microprocessor chip card is a distinctive medium for expanding and taking up the market of those service performances that must interfere with protected data. This microprocessor chip card can be used as a means of payment, a counting unit and for storing values. She can, as is consistent with the customer's wish, be the customer himself and, after the card is issued, equipped with flexible additional services and initiated to manage them. She also actively checks the authenticity of access of the participating terminals and ensures the uniqueness and authenticity of the data transmitted.

Fig. 2 shows a clear arrangement of the system. It shows the components of the system. The system operator (System Operator) makes the system available. At the service terminals (ST), VAS applications can be charged, deleted and transferred; other operations are: selection of VAS applications, browsing, interpretation, etc.

VAS application offerers The VAS Providers design their own VAS applications according to the framework conditions of the system operator and, if possible, according to their own ideas. By terminating with a digital signature, the corresponding terminal programs become verifiable for authenticity.

Fig. 3 shows the data flow in the system.

VAS applications are prepared by the system operator for use at card user terminals. The VAS applications are charged to the VAS-Container of the chip card of the invention before being able to participate.

At the trading terminal (HT), the VAS applications that are available on the card are used, while the VAS data is stored, respectively. deleted.

In order to implement a microprocessor-based chip card with VAS functionality, it is placed on the VAS-Container card in addition to the existing methods of use (eg payment applications such as electronic money exchanges).

The VAS Container uses features that allow you to locate, delete and transfer VAS applications. These control functions are used exclusively by the Operator system and are secured against unauthorized use on the card. The VAS Container includes a conversion memory with which data is exchanged between applications

VAS.

Two commands TRANSFER and ΤΑΚΕ are introduced to control the transfer memory. The TRANSFER command creates a record in the transfer memory with a specific-

data necessary to control the processing, such as date, date of forfeiture and identification data. The ΤΑΚΕ command removes objects from the transfer memory and is referred to as removed. Depending on the application, the objects are then marked as valid or invalid. The transmitted data is tested for authenticity and uniqueness by the VAS Container.

VAS applications use VAS to prepare and manage ways to use VAS data. Access to VAS data is controlled by the VAS application, which is operated by mechanisms that are prepared in the VAS Container for all applications. VASProvider operates one or more VAS applications in the VAS Container. The use of the VAS application is defined by the location, reading and processing of VAS data.

VAS Container supports interservice. Interservices require access to common data, transfer of performance claims and performance billing between different partners.

In the following, the services or examples are to be shown in the examples. applications possible with the smart card according to the invention.

The description always refers to the manner of release and function of the prior art. The function is to be completed in the future by one or more VAS applications.

DETAILED DESCRIPTION OF THE INVENTION

Intraservis will be introduced first.

Example A: Customer Club

The department store is run by a customer club. The customer is a member of this club and, with this status, receives specific club benefits that non-members cannot receive. Today, a member is identified in the vicinity of the club by a club card. The club card is issued upon entry, is not transferable and usually has a validity period. There are no specific transactions on the club card, i. there is no link to customer turnover. This limits the club card from bonus programs where there is a link between status and turnover.

Analogue: wholesale card, senator card, club book

Objective: Club membership should be demonstrated by application in the VAS-Container.

Example B: Bonus system

The customer receives a bonus claim for each transaction. The bonus claim is cumulative and may be exchanged for a monetary value performance at a point defined by the customer. The bonus claim is valid for a defined period of time and can be managed anonymously or in relation to a person. The bonus entitlement arises from turnover or frequent use.

Analogue: Miles & More score

Objective: The point account is to be managed by an application in the VAS Container.

Example C: Rabat

The customer receives a volume rebate on schedule. The rebate lasts for each individual transaction. The card does not manage any turnover history. Each transaction is closed in itself.

Objective: The claim for rebate is to be demonstrated by the application of the VAS.

Example E: Price units

Pricing units are obtained and consumed one or more times. Each transaction decreases the value by one or more units. The Usage Authorization is transferable and may include a Usage Restriction.

Analogue: Single ticket, penalty ticket, subscription concert ticket, ten-squash voucher, cinema ticket, telephone units

Objective: The arrangement should be rationalized by the application of VAS.

Example F: Usage Billing

The use of the power is registered by time, frequency or quantity and charged according to the tariff plan. It is not known in advance to what extent the performance will be revoked.

Analogue: Board Bon, short-term parking ticket

Objective: The VAS application is intended to enable billing by tariff.

The relevant current billing data should be stored in the VAS Container.

Example G: Notepad (mobile memory)

This application allows VAS-Provider card owner data to be uploaded. This automates procedures that have so far been handled manually. No monetary consideration can be derived from these data.

Analogón: Filling in lotto tickets, shopping card, cash register, phone book

Objective: The VAS-Provider is to collect the card data and thus be able to directly prove the corresponding service (eg to arrange a telephone connection, compile the required goods, fill in the lottery ticket electronically and submit it). The data can have both a short period and a long storage period on the card.

Following these examples for intraservis, several examples for interservis will now follow.

Interservis always arises when several VAS Providers participate in the service. This is inextricably linked to the fact that the data leaves the scope of one VASProvider. Today it happens with receipts on paper.

Example A: Travel compensation

The department store pays to the customer the ÔPNV- business ticket for the trip to the department store. The customer must present individual travel tickets to the department store. The department store notes on the ticket that it has been paid. Alternatively, the department store will receive part of the customer's refund from the transport company back.

Objective: The replacement process is to be carried out electronically.

Example B: Travel credit

The department store reimburses the customer for the cost of traveling home, and a credit note is issued for this purpose. The customer receives tickets ÔPNV, respectively. pays a reduced ticket price. The transport company bills the credit note with the department store.

Objective: Expression of mechanisms by VAS applications with electronic settlement between trade and aPNV.

Example C: Customer parking space

The department store pays a part of the parking fee to the customer when using a certain parking lot. The parking lot is operated by an independent company and receives a cash refund from the department store for every billing to the customer's benefit.

Objective: Expression of mechanisms by VAS applications with electronic billing between the shop and the parking lot.

Example D: Multilateral bonus program

A group of commercial enterprises and service providers are united in a joint bonus program.

Goal: Each partner can credit or reward bonus points on a common account on the card. Performance reporting between partners is performed by a background system.

Example E: Recognition of bonus points among service providers

Each service provider operates his own bonus program, but has agreements with others to recognize the points earned. Well-known examples are agreements between car renters and airlines to collect 'miles'.

Objective: To support the transfer of bonus points by card. Every VAS-Provider has to earn his / her bonus points first, without having to hit another. Reliable mechanisms are to be prepared for transmission.

Example F: Night taxi

At the same time, the ÔPNV travel license will acquire the entitlement to travel in a pick-up taxi (eg after 10 pm). The undertaking operating the taxi must prove to the bill that the travel license has been presented. The use of a taxi is recorded on the card to prevent abuse.

Objective: The VAS application is intended to enable the use, control and billing of this service.

In the following, the chip card composition according to the invention is to be described in more detail.

A microprocessor-based chip card with VAS functionality mainly contains a VAS-Container.

The VAS-Container is a stand-alone application and exists either alone or in parallel, among other applications, on the basis of the card underlying it. The VAS Container is fully self-defined and functionally capable. It can be operated without a payment function, which is usually available on the same card. In particular, an independent security architecture is defined for the VAS-Container so that VAS applications can use separate security functions.

Value Added Services is a customer transaction that takes place at VAS-Provider terminals. VAS-Provider wishes to monitor these transactions, whether for system surveillance or for the collection of statistical and other data. To optimize and unify the data structures in the card, it discourages the use of application-specific identifiers and the use of a system-wide unique VAS Container ID is recommended. This number can be used by the VAS-Provider to implement o.g. functions and it frees him from the burden of managing his own number circles.

The VAS Container security architecture uses this system-wide unique ID to derive a specific key card. The use for a specific number card would in principle be possible, but it is not used, since if the VAS-Container is implemented on different bases, these bases use conflicting numeric circuits as appropriate.

The VAS-Container ID is entered from the System Operator and carried to the card issuer when creating the VAS-Container. With the lubrication of the VAS Container, it is destroyed and thus removed from the system. The VAS Container is deemed deleted when it does not contain any VAS applications and the VAS Container ID is deleted.

When the VAS Container is transferred from old to new, it is carried out together with the VAS VAS Container ID applications. This transfer corresponds to the transfer of the VAS-Container from the old card to the new card. The old card does not contain any VAS Container after this action. The VAS-Container available in the new card will be overwritten during this operation and thus deleted. Since the VAS Container ID is transferred from the old card to the new card, there is no need to change the reference numbers in the VAS Provider background systems.

The individual VAS applications can only be moved between two different VASContainers under the supervision of the respective VAS-Provider. With this function, the assignment between the VAS Container ID and the VAS application is changed, which among other things must be recorded in the VAS Provider's background system.

The VAS-Container does not contain any person-related features. VAS applications may contain personal data; however, their volume should be kept to a minimum to protect data and improve memory usage. VAS applications should, if necessary, store data relating to persons in the background system and create a card assignment using the VAS Container ID.

An essential feature of the VAS-Container is the support of interservice. Interservices require access to common data, transfer of performance claims and performance billing between different partners. The VAS Container must allow this and still ensure the security of intraservised applications.

The so-called VAS Intraservis applications are applications that are operated under the exclusive control of VAS-Provider. The VAS Provider defines the security of its application independently of the external location. Without the transfer of the keys, no external party can change the VAS data.

In order to effectively derive interservice, partners must be able to intervene in common data. Common access to data is realized by differentiated security mechanisms.

The first stage of the common approach will be carried out exclusively through public transfer fields. VAS Providers can exchange data through these fields without having to know applications and keys with each other. Only for writing data to the conversion fields, the terminals must have suitable keys, but not for reading. Everyone is free to read. Data exchange can take place in both directions between the VAS-Provider and the partner, each with its own key. Conversion data may be generated from the VAS VAS-Provider intraservice application or conversely, the VAS-Provider may download data from the conversion field to its VAS intraservice application.

The second stage is the depreciation of the value units that are embodied by VAS data. The VAS Provider delivers value units to VAS data with a special writing key. Value units can be used by interservice partners who have the impairment key they receive from VAS-Provider, who has overall responsibility. At this stage, partners with different rights interfere with non-public VAS data.

The third stage is direct access to VAS data for writing by all involved interservis partners. This method requires an adequate level of trust between the parties since the VAS data can be changed indefinitely.

The transfer field serves as a link between VAS applications. The conversion field data is generated from VAS applications in the VAS Container. The data can also be directly entered in the conversion field when the manufacturer does not operate any own VAS applications in the VAS Container.

The transfer field is available to all applications in principle, but only the person who has the authorization (key) can write. Only by the rules, i. Rules and Regulations R&R authorized recipients may remove data from the conversion field. The recipient tests whether the transfer data specified by the recipient are available and takes it for processing in its own system.

In order to prevent manipulation of the transfer data in the public exchange, the manufacturer enters the identity mark and the VAS-Container sequence number. These elements ensure the uniqueness of the transfer message and prove the origin of the data.

Where appropriate, the manufacturer of the data transferee shall be able to carry out the authenticity test. If such a wish is not expressed, the data can be accepted according to faithfulness and faith; The authenticity mark shall be checked, inter alia, when it is charged in the background system of the producing VAS-Provider.

Data can only be removed from the transfer field once it has been authenticated. When the data is collected, the data is recorded and (as copies) remain in the conversion field. As a result, the conversion process can also be demonstrated after the data has been collected.

The data in the conversion field contains the date of the forfeiture. Dropped data can be overwritten when any application is needed. The data in the conversion field can be recorded as they are overwritten so that they are freed for immediate overwriting. However, if the memory should be completely full before the conversion data file is overwritten, the card owner no longer needs to delete the necessary entries on the service terminal.

Three operations are defined to model VAS applications. These operations affect VAS data. Charging and deleting applications are functions of the VAS Container and will not be addressed in the following paragraphs.

Acquisition (Acquisition) Generally, obtaining a claim for performance and postponing the license to VAS data of the VAS application.

Impairment In general, the payment of a claim without or with full or partial use of VAS application data. The process produces an electronic quantity that is set aside in the conversion field. This quantity contains a meaningful forfeit date on which it can be deleted from the transfer memory.

Taking In general, removing the electronic quantity from the transfer field for further processing (eg background system). A copy of the quotation remains and serves as an 'impairment' document.

The "retrieval" of VAS data is only possible through the respective VASProvider. 'Impairment' may only be carried out by the VAS-Provider who created them by 'acquisition' or by means of an inter-service partner authorized by the VAS-Provider. 'Removal' may also be carried out only by any other VAS-Provider. In the case of interservice without equal access to VAS data, the partner excludes the transfer of the “withdrawal” status. The electronic quantity thus obtained can then be billed by the Operator system and the VAS-Provider background system. “Acquisition” and “Impairment” can be done in one step.

VAS applications with common features can be divided into classes. The classes form the basis for data structures in the VAS Container. The VAS Provider chooses an application class when implementing its use.

The following application classes are defined:

• Point memory • Ticket • Card • Credit memo • Data memory

Point memory indicates the application class in which the point value account is managed. Values can be booked and written to the point account.

Values are booked by the VAS-Provider, while a new account state is written to memory. The value is de-booked by means of an 'impairment' operation, whereby the electronic quantity is put aside in the transfer memory. Both functions are accessed using two different access keys.

A ticket denotes an application class in which a value field exists that is depreciated one or more times and thus consumed. The book entry values in the ticket class apply once.

The pass identifies the application class for which the VAS data contains an authority pass. The card is usually not consumed by use, but becomes invalid according to a defined criterion, e.g. after a time-lapse. Each time the application is created, the authenticity of the card (eg a citizen's parking ticket) or the card template (eg a collection taxi trip to a monthly ticket) is documented: Creating an electronic quantity using a card. the use of the card can be documented in the card's memory.

A credit note refers to an application class whose performance requirements (typically with a short period of time) are stored in the card for a while. These electronic credit memos are only stored in the VAS Container transfer memory. Typically, the credit app evaluating application is different from the one that creates it. The credit memo can be withdrawn from the transfer memory only once and is documented in the card. The authenticity sign created by the VAS-Container can be used for billing in the background system.

Data memory is the designation of the application class where the VAS-Provider stores data in the VAS-Container that offers the customer additional service (eg last menu in Fast-Food Restaurant, last lot numbers, service preferences, suggestion lists). The data are for information purposes only and do not represent a claim for performance against the VAS-Provider. Data access is controlled by the VAS-Provio UPDATE RECORD command, which must be preceded by external authentication with the KLvasp key ·

Read access to all non-internal VAS data is allowed only if the previous Krvasp or Kso key authentication or correct PIN or password is entered by the system operator. PIN- or password-protected access is provided so that the cardholder can view the data on the terminal or in Wallet. At the service terminal, the card holder has the option for all applications to be activated simultaneously. deactivate protection by PIN or password to read value or status data.

The global data of the VAS Container includes the key K _S ig_vacs to sign the data collected from the conversion field. According to the signature, the integrity of this transaction data may be examined when it has to be transmitted through secure manipulation between interservice partners for billing purposes. In addition to the signature entered by the interservice partners of their choice, a Ksig.vasc-based signature and a transaction counter managed by the VAS-Container shall be added to the data records issued by the card through the "take" operation. Since everyone is allowed to read the transfer field, but the card signature with Ksig.vacs is created only when invoked (and this can only happen once), an unacceptable double bill is recognized from credit notes. Each interservice partner can have the system operator confirm the authenticity and uniqueness of the credit memo taken. In addition, the authenticity of the VAS-Container can be demonstrated by the system operator by a signature test.

If the card base were to support an asymmetric key method, as a Ksig_vasc, a private (secret) key inside the card could also be added to the signature, or such a key could be derived from a private Key Generating Key. In this case, the VAS Providers could add public (non-secret) keys to their own signature testing without consulting the system operator.

The VAS Container data includes the Global Key Generating Key KGKdec, which can create an access key for all terminals of all VAS Providers to validate the "take-off" operation (more on key derivation and testing is described below). For the depreciation of monetary data, the same security measures as for charging or charging are not placed. claiming. Here, you only need to use the global key instead of the custom application key. This global key is first converted to an application key and then re-derived to a terminal key. Only application-specific derivation of the global key for the development of its own terminal key is passed to the VAS-Provider. This will be explained briefly below:

We denote the mack (k, d) calculation of the Message Authentication Code for message d and DES-key k via DES. If the message is no longer than 8 bytes, this corresponds to the encoding itself (ICV assumption = 0). We denote macp (k, d) calculating mack (k, d) with the following adaptation of parity bits. The result k '= macp (k, d) is again a valid DES key.

The application-specific terminal key is calculated as follows:

1. Each card stores a key

KGK _D ec, which is the same for all cards, and which is the secret of the system operator. The system operator prompts this key to be personalized in the card.

All VAS application keys and terminal keys can be derived from this key.

. VAS Provider could deploy VAS with AID _a = RIDvas.PIXa · Now calculates system operator from KGKdec and PIX application-specific key

KGKdec, pjx macp (KGKdec, PIXa) and passes this key to the VAS-Provider.

3. This VAS-Provider derives its specific keys from KGKdec.pix for all terminals to use the TRANSFER command for VAS A using its terminal ID:

Kdec = macp (KGKDEc, pix> Terminal ID) = mcp (m acp (7777ALD _{£ C} , PIXa), Terminal ID

The VAS Provider has these keys stored in its terminals. Unless the VAS Provider itself operates terminals, it generates keys and distributes them to terminal operators.

4. The VAS card executes the TRANSFER command only if the command contains a terminal-generated cryptogram C that generates message data in the transfer memory via the data. The card itself recognizes KGKdec and receives from the terminal, in addition to the utility data and cryptogram C, the ID terminals and the appropriate PIX (or the PIX card knows PIX itself, see also the TRANSFER command description). Now the card itself can calculate the cryptogram C 'with the utility data:

mac (macp (macp (X ^, GÄoFc> PIX), terminal ID), data) = = m & c (m & cp (KGKDEc.pjx, terminal ID) data) = = mac (K _DE c, fata) = = C '

The card now compares the calculated cryptogram C 'with the terminal C calculated by itself. If they are different, the transaction is interrupted with an error message. In case of a match, the VAS-card will execute the TRANSFER command. Different safety measures are justified for different types of construction of service terminals. trading terminals (for charging or retrieval) and simple trading terminals (for depreciation). The terminal must be authenticated against the card to perform a Kdec Key Impairment operation · When compromising a Kdec key, the attacker can only perform its terminal functions. However, this procedure is logged in the tab. The documentation includes a unique sequence number, spoilage and terminal ID. VAS applications use the VAS Container security services to regulate access to VAS data. The performance of the specific functions of the PRS is limited by the definition of access rights to authorized parties.

In general, publicly accessible data areas (eg for reading Wallet values) and the private data areas of the responsible VAS-Provider must be made available for each VAS application, which may protect others from access (for example, internal administrative data).

Since the ISO 7816-4 cards for individual Records von Elementary Files (EF) do not offer any differentiated access protection, multiple data sets must be used that contain the appropriate notation to show different views of the VAS application.

Thus, for application classes, point memory, ticket, ID card and data memory can be implemented differentiated access protection by dividing the VAS data into four Elementary Files, as shown in FIG. 6th

Four Elementary Files contain these data, respectively. are protected as follows:

Table 3 - Overview of data files

field Contents Typical applications Access protection EF. .KEY Contains keys The VAS-Provider must Klvasp, Krvasp check Klvasp before he can which he only knows write to EF_INFO VAS- Provider. EFJNTERNAL a EF_VALUE, or than (Note: may read data of EF_INTERNAL For VAS applications The terminal must be verified and optionally for Bloody before he can read the data card is always entered by VASProvider) from EF_INFO, EF_VALUE EF. _INFO nevnútorné ticket information Contents of this data information about bonus information units can be applications program written only VAS- provider VAS card information (external verification park information. knowledge of Klvasp). tickets Reading should be possible

only on terminals that have Krvasp or Kso. or the card owner gives the correct PIN.

(The card owner can disable PIN protection.)

EF_INTERNAL Internal data Internal counters, Contents of this VAS data application, account statuses, units can only be written and read to the control, additional to the VAS-Provider, keys for:

- bonus programs

- the degree of rebate

- hidden characters> card

- Access protection codes are based on external verification of knowledge of KlvaspEF_VALUE Value Units of VAS

This data unit contains the bookable values of the VAS Provider application

Only the VAS Provider can explicitly write these values (external knowledge validation of Klvasp) · By default, the value can be reduced by the "impairment" command issued by the partner authorized to perform the function by the VAS-Provider (a signature of the impairment operation using Kdfc). INFO.

- Account status

- the residual value of the ticket

- how much is good for him

- usage counters

This Elementary Files (EF) structure supports access rights for all application classes.

same differentiated

While only application classes of the same kind are collected in one implementation class, which determines the number and size of Elementary Files, the memory assembly can be minimized by varying the space required for applications. The application classes point memory and ticket need the same resources EF_KEY, EF_INFO, EF_INTERNAL, EF_VALUE and are therefore collected in one implementation class “DF_PT”. For the Pass and Data Memory application classes, the Elementary Files EF_KEY and EF_INFO are sufficient and will therefore be collected in the DF_AD implementation class. Assessed in terms of number: There are p objects of the implementation class DF_PT and objects of the implementation class DF_AD, to which the applications of VAS application classes can be charged point memory and ticket, respectively. card and data memory.

Especially for the credit memo application class, which should include public read accesses for all VAS participants for common data exchange, the implementation field conversion field is used. Writing accesses are possible only indirectly by using a TRANSFER statement that requires a correct Kdec signature. This implementation class consists exactly of an entry in the EF_TRANSFER Elementary Filé that belongs to the VAS_ Container global data. Objects of this class are Records in this dataset. We also call this implementation class "EF_TRANSFER".

Within the VAS-Container, the implementation classes shown in FIG. 7. These implementation classes form the VAS Container memory model.

There are two ways to prepare a memory model available. The choice depends on the card base:

Fixed memory range for VAS Container:

For the implementation classes DF_PT and DF_AD, the Issuer always determines its maximum number p, resp. and objects and those Issuer charges the CREATE FILÉ to the card. Objects are denoted DF_PTi, resp. DF_ADj. VAS applications can be charged at a later point in time, i.e. other VAS applications of unoccupied objects. For charging, resp. then only UPDATE RECORD commands are needed to delete VAS applications.

Thus, the issuer determines the number of possible objects of both implementation classes according to its own needs; this may not necessarily coincide with the cardholder's actual use behavior. The layout is held throughout the card's lifecycle. The VAS application is loaded into an object that is from an eligible implementation class. Thus, e.g. put the VAS application that represents the license into the DF_PT implementation class when there are no more DF_AD implementation class objects available. Assigning a VAS application to an object is done by entering the coordinate assignment (VIX application PIX, busy object FID, unencrypted application text name) into the VAS Container EF_DIR global data set. Deleting an application corresponds to deleting this coordinate assignment from EF_DIR and destroying the read (UPDATE RECORD statements) of the memory occupied by the application.

This variant is used for basic cards that do not support dynamic creation, respectively. lubrication of DF / EF structures.

- Dynamic creation of implementation class objects:

For each VAS being loaded, the CREATE FILÉ statements are created for the data sets needed for the implementation class that is the basis. When deleting a VAS application, its DE / EF is completely removed from the card and free up memory space. The maximum number of implementation class objects is not explicitly determined by the Issuer here, and depends only on the available memory space in the card.

This variant requires dynamic memory management by the card's operating system.

In the present embodiment, we start from the first variant because it places the second increased requirements on the available card base. However, if dynamic memory management is available and it is ensured that dynamic object creation can save more memory than the message costs, then the existing concept can be adopted and offer the card owner more flexibility.

The data structures and commands with which the VAS Container can be implemented and the VAS customer card functionality compared to other system components will be presented. In addition, VAS operations that describe the relevant interaction between the VAS-Container and the terminal are determined for typical business cases.

The implementation is based on the following assumptions:

• At the merchant terminal, each card provides the same data and command interface independently of the card. The necessary commands are therefore clearly described in their coding.

• The service terminals are capable of recognizing the card base. Functionality can therefore be achieved using specific base commands. These processes are therefore partly informative described. How this function is prepared is left to the card manufacturer.

In FIG. 7, various implementation classes of the VAS-Container are shown schematically. Fig. Fig. 8 shows schematically the structure of VASContainer data sets; 9 schematically shows the structure of data sets of the implementation class DF_PT; FIG. 10 shows the structure of the DF.AD implementation class data files.

Access to VAS Container data files is explicitly restricted by the following Access Conditions (AC):

Table 4 - Conditions for access

Datel ADMIN Read access Writing 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 KSO NEV NEV (X = PTi..PT _D , ADj .. Ad. EF_KEY KSO NEV KSO EF_INFO KSO PIN or Krvasp or Kso Klvsap EF_INTERNAL KSO K LVASP K LVASP EF.VALUE KSO PIN or Krvasp or Kso Klvsap

AC has the following meanings:

• ALW (Always) = Data file command always allowed • NEV (Never) = Data file command never allowed • K _S o ~ Authentication must be performed before access System Operator key Kso- • Klvasp = Before access the external VAS-Provider must be authenticated with the Klvasp key. • Krvasp = An external VAS-Provider-authorized terminal must be authenticated with the Klvasp key before access. • PIN = The cardholder must enter the correct PIN in plain text with the VERIFY command before access.

• PIN or RVASP or Kso = before accessing cardholder must be specified either correct PIN or takes place external verification VAS provider using RVASP or System Operator by K _with.

It should be noted that the binding of "or" access rights as described above in the card's operating system is generally not provided. Alternatively, it entails a particular implementation cost. (Option: special READ command with default security attribute specified).

The data fields within the Records Elementary Files are distinguished by the following formats: ASCII, Binary, BCD, Date, Formatstring.

Formatstring data elements contain VAS data in a densified representation that can be shown to the card holder at the terminal.

For optimal memory usage, unencrypted text and binary data are mixed and can be represented using formatting macros.

All VAS Container Elementary Files (EF) are defined according to ISO 7816-4 as linear formatted EF data files with constant fixed records (linear fixed record files).

Elementary Fillet EF_ID of DF_VAS consists of a Record containing a VAS-Container ID.

Elementary Filé EF_DIR of DF_VAS consists of nrnm Records. For each VAS application loaded into the VAS Container, the Record from EF_DIR of its Proprietary Identifier Extension (PIX) and its physical memory location (FID of the DF_X to which the application was loaded) will be retained. The PIX identifies the application and the Service Provider to which the application is assigned, e.g. as a brand.

The entries in EF_DIR on the system operator's service terminal are created dynamically. Records without records are created with an empty LTV object '61'.

When charging a VAS application, it first seeks free memory space for the appropriate implementation class, certain VAS data is recorded there, and a new Record is created in FE_DIR.

When deleting an application, an empty LTV object must be written accordingly in the EF DIR.

Elementary Filé EF VERSION of DF_VAS consists of a Record containing the version number of the VAS-Container.

in

The version number can be used by the terminal to distinguish between different VASContainer variants and / or different software versions.

Elementary Fillet EF_SEQ of DF_VAS consists of Record, which contains the number of the next transfer field record.

The sequence number is read from the additional TRANSFER statement. This command therefore creates an EF_TRANSFER Record in the conversion field to which, inter alia, the sequence number from EF SEQ is transferred. Along with the ΤΑΚΕ order, which ensures that each Record is taken from the transfer field only once and this subscription is documented per signature by a sequential number, a single subscription can be guaranteed by (original) credit notes or, possibly, by credit.

The transfer memory will be discussed in more detail below.

Transfer memory can be read without limitations, but write access is only possible using specific VAS TRANSFER and ΤΑΚΕ commands.

The assignment of data fields with the TRANSFER command is done by the Last- recently-used algorithm. The oldest Record in the data file can be found by searching for the smallest value in the first two bytes of the Record.

Data fields can be marked as removed and / or deleted by the ΤΑΚΕ command in the cache. In any case, data is erased in the transfer memory by overwriting the new data.

Each Record in the transfer memory contains, for example, the date of forfeit terminal ID, PIX, sequence numbers and possibly other data.

Each Element_Filter EF_INFO within the DF_X lists (where X = ΡΤι.,. ΡΤρ, ADi .., AD ₃ ) consists of a record containing the forfeit date and general VAS data of the VAS application. For example, a type of ticket (single or strip ticket) or boarding place may be provided. However, EF_INFO must contain at least an unencoded application name that is readable for the VAS application browsing operation. Sensitive data must be protected by VAS-Provider using appropriate external encryption algorithms.

This EF is readable when external authentication using Kso or Krvasp is performed or the cardholder enters the exact PIN if PIN protection is activated.

Each Elementary Fill EF_INTERNAL within DF_X lists (where X = PTi ..... PT _p , ADi, ..., AD,) consists of a record that may contain internal VAS VAS-Provider data with its loaded VAS application. Neither the cardholder nor any other VAS-Provider can read this internal data.

Each Elementary Fill EF_VALUE within the DF_X lists (where X = PTi ..... PT _p , ADi, ..., AD _a ) consists of a Record that may contain a value field of integer VAS data numbers. This EF is readable when external authentication is carried out using Kso or Krvasp, or when the cardholder enters the correct PIN if the PIN protection is activated. correct password.

The VAS Container or VAS application uses the key field below. Next, it is based on pure DES coding. I all VAS Container keys are DES keys and are coded in 8 bit code (including parity bit).

Within the VAS Container and within the VAS applications, the following keys may be recommended by their KID (Key Identifier):

Table 5- VAS Container keys

KEY KID K _so '00' Kaut '01' KsiG VASC '02' KGKdec '03'

Each key is associated with an operator error counter. It registers failed authentication attempts with this key and blocks further usage when the clogged limit is reached for this counter.

Within VAS, the following keys may be recommended by their KID:

Table 6 - VAS application keys

KEY KID K LVASP '04' RVASP '05'

Each key is associated with an operator error counter. It registers failed authentication attempts with this key and blocks further usage when the clogged limit for this counter is reached.

The VAS Container contains a personal identification number or password (PIN). This is used by the VERIFY command to identify the card holder. The PIN is associated with an operator error reader that registers each wrong entry and closes the PIN comparison when the limit is reached. This cap can be removed using System Operator with a suitable administrative command. The operator error counter returns to the default state when the PIN is correctly entered.

There are the following parameters for the VAS-Container which the cardholder can, depending on the location available on the card base and on his / her individual wish:

• p Maximum number of objects of the implementation class DF_PT = maximum number of VAS applications of the application classes point memory and ticket that can be simultaneously loaded into the VAS-Container;

• and maximum number of implementation class objects DF_AD 'maximum number of implementation class DF_AD = VAS applications and a data memory that can be simultaneously loaded into your Vas Container;

• nroiR maximum total number of objects: nroiR = p + and the number of Records in EF DIR is nR • nrEF_TRANSFER number of Records EF_TRANSFER

The memory requirement for the quantities described by Elementary Files is:

byte Global VAS Container data: EF_ID 4 EF_DIR 9 * (p + a) EF_VERSION 1 EF_SEQ 2 global Keys.Pin 64 + 2 Transfer Field: EFTRANSFER 48 * nľEF_TRANSFER VAS-Provider property data: EF_KEY (P + a) * 32 EF_INFO (P + a) * 62 EF_INTERNAL P-10 EF_VALUE P-3

If we choose eg. for the parameters p, a and nr £ F_TRANSFER the following values then the minimum requirement for the VAS Container (without the need for additional command memory) is as follows:

Parameters p-8, a-3, nrEF_TRANSFER - 15 = 10, a = 5, nr £ F_TRANSFER ⁼ 20

Memory needs

2030 Byte

2758 Byte

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

Next, we will now deal more precisely with the smart card commands of the invention.

The READ RECORD command is used to read data from linear Elementary Files. The card will provide the contents of the Record in the feedback. EF is recommended by Short Filé Identifier (SFI).

Status Code '9000' indicates successful execution of the command; any other code is considered an error.

The UPDATE RECORD command is used to input data to the Linear EF Records. The command message contains recommendations for EF, Record and data.

The response card contains the Status Code. Status Code '9000' indicates successful completion of the command. Other Statuscodes point to a faulty case.

GET CHALLENGE requires a random number from the card. The random number is used in conjunction with dynamic verification on EXTERNAL AUTHENTICATE.

The responsible message card contains 8 bytes long random number and Statuscode. Statuscode '9000' shows successful execution of the command. Other Statuscodes point to a faulty case.

The EXTERNAL AUTHENTICATE command allows the terminal to be authenticated against the card. EXTERNALE AUTHETICATE is used within the VAS applications to authenticate the Operator and VAS-Provider systems. EXTERNALE AUTHETICATE transfers a cryptogram to the card, which the terminal must first create by encoding a random number. The card compares the cryptogram to a reference value that it itself calculated using the same method. When both values are the same, the card internally records that the access condition validation for this key is successful. If the comparison is to be negative, the status card responds with unauthorized status and decrements the internal operator error counter. When this counter reaches 0, any further execution of EXTERNAL AUTHENTICATE with Validation Status will be rejected.

The card response message contains Statuscode. Successful execution of the command and terminal verification against the card are reported by Statuscode '9000'. Other Statuscodes point to a faulty case.

The INTERNAL AUTHENTICATE command is used to check the authenticity of the VAS-Container by the terminal. For this purpose, the card calculates the cryptogram using the reference data from the terminal. The terminal creates a cryptogram on its side and compares it with the card value. In case of equality, the terminal can accept the authenticity of the VAS-Container.

The card response contains a cryptogram and Statuscode to execute the command. Successful execution of the command is reported by Statuscode '9000'. Other Statuscodes point to a faulty case.

The VERIFY command is used to verify the cardholder PIN. The command transfers unencrypted PIN data to the card, where a comparison is made with a reference value stored in the memory. When the entered and stored value is identical, the PIN access condition is considered to be fulfilled.

The card response message contains Statuscode. Statuscode '9000' indicates that the command has been successfully executed. Other Statucodes point to a faulty case.

The TRANSFER command creates a record in the transfer memory. Three working modes are defined for the command:

1. Create a transfer memory entry by reducing the values in the EF_VALUE field of the ticket class application or point memory.

2. Create a record in the conversion field by issuing an amount in the license class applications.

3. Create a conversion field record by issuing a credit note in credit note applications.

The working mode is automatically selected by the card: When the command is executed within the selected DF application, it is first checked if EF VALUE is available. With the available EF_VALUE, the card executes the command in mode 1, otherwise in mode 2. When no application DF is selected within the VAS-Container, mode 3 is used.

The terminal supplies the card with the following data when the TRANSFER command is called:

• Current date • Drop date for transfer field entry • Identification for terminal creating this entry • Transfer field utility data • VAS PIX (Mode 3 only) • Number of units read • MAC with o.g. data, sequence number and VAS Container number.

The card performs the following sequences when the TRANSFER command is called:

1. Search in the read-only memory. (The calculation below reproduces descending priorities in which available records are to be overwritten: Record Recorded as Deleted, Record Recorded as Taken, and Reach Date of Drop).

2. Connection of PIX to data from the terminal in modes 1 and 2.

3. Attach sequence numbers to file 2 data.

4. Attach the VAS Container ID to the data in file 3.

5. Derive KGKdec.pix by encoding PIX under KGKdec.

6. Deriving Kdec by encoding terminal IDs under KGKdec.pix-

7. Create a MAC with the data from step 4.

8. Compare the MAC from step 7 to the MAC from the terminal. When the values are different, the card interrupts the function and decreases the error counter for KGKdec- ·

9. For Mode 1: Test the value field EF_VALUE in the list to which the application has been charged. If there are not enough units available in this field, the card will stop at this location. In other cases, the value field in the app is reduced by the amount.

10. Compilation of the command message.

11. Increment EF_SEQ content by 1.

Therefore, it is not necessary to release the data file in the response. Furthermore, it may be accepted that the Record number is known.

The ΤΑΚΕ command provides the following modes:

• Subscription with a current clause stating that the data has become invalid;

- · · Collection without previous clause. Data remains valid.

The command message contains a terminal ID field, an application PIX field, and a random number generated by the terminal.

PIX in the command indicates use for collection. It may be different from the PIX data file that is being removed. It is used solely to derive the Kdec subscribing terminal.

The card response message contains a cryptogram with K _S ig_vasc with Transfer Field Record data and a VAS-Container ID, a cryptogram C ₂ with a Kdec subscriber terminal of Ci and a random number from the command message. The reply message contains the Statuscode appendix. The Kdec key is derived as described above. According to the cryptogram, the authenticity of the license is implicitly proved by means of the VAS-Container. With the C cryptogram, proof of authenticity and uniqueness are calculated (because C is generated using a sequential number, a Transfer Field Record bit, and a VAS Container ID) that can be verified by the System Operator.

Statuscode '9000' indicates that the command has been successfully executed. Other Statuscodes are interpreted as errors.

It should be assumed that the SO proposes AIDvas according to ISO / IEC 7816-5. More specifically: He proposes a 5 byte long RIDvas for the VAS system.

The AID of your DF_VAS list should read: AIDvas = RIDvas-PIXdf_vas ·

The command message includes, for example, a field with a forfeiture date, a terminal ID, transaction data, a field for a mode of operation (e.g., in PIX mode 3), and a cryptogram.

The cryptogram is calculated using the Kdec key, and the data used to create the MAC include, for example, transaction data and terminal ID.

The response message of the TRANSFER statement contains an 8 byte long data field and a byte long Statuscode '9000'. Response messages with a different '9000' statuscode are interpreted as an incorrect code. The data field of the response message contains an encoded cryptogram of the command message in the flawless case (i.e., especially when the response message cryptogram was correct). This implicitly (instead of internal verification using K _A ut) proves the authenticity of the VAS-Container.

The ΤΑΚΕ command is used to play objects from the EF_TRANSFER implementation class. Technically, executing the ΤΑΚΕ command means reading the specified Record from the EF_TRANSFER dataset, while the Record remains in the dataset until space is needed for new records; the data file is recorded as removed. Technically seen, anyone can use the ΤΑΚΕ command to remove a data file; according to R&R, however, this should only be done by the VAS-Provider intended for the data file.

The following procedure is available for the collection: The VAS-Provider, which wants to take a credit note or a quantity, searches the cache according to a suitable data set (eg using the SEEK command or by explicitly reading each Record). The data file is in any case read and possibly content tested.

For each VAS application, according to R&R, A is entered as a 3-byte long PIXa so that they can be uniquely identified within the VAS Container with the AID _a = RIDvas-PIXa · After selecting DF_VAS, the list in which VAS A is contained can be selected using SELECT FILE <PIXa>.

Let UPDATE KEY (KID, K) be marked with a command based on the card base to replace the Key Identifier ID key with a new value.

Before the cardholder can use the VAS application of one of the implementation classes DF PT or DF_AD (corresponding to the application classes point memory, ticket, ID card or data memory) at the merchant terminal, it must be charged to the VASContainer's service terminal . In principle, it is also possible for the card issuer to charge one or more VAS applications when stored in the VAS-Container as commanded by VASProvider and SO. This charging procedure is a special case described herein.

VAS charging process:

1. The cardholder shall insert the VAS card into the service terminal.

2. The service terminal checks whether the VAS Container is available:

• SELECT FILE <AIDvas> (Error message when VAS Container cannot be selected) • READ RECORD <SFI of EF_ID, 0> (Read VAS Container number)

Optionally, the validity of the VAS-Container is tested. To do this, the service terminal requires the internal verification of the VAS-Container:

• INTERNAL AUTHENTICATE <Case number, KID from K _A ut> The service terminal tests the response and interrupts (with error message).

3. The service terminal gives the card holder a choice of several offers. One of them is Charging the VAS application. The cardholder chooses. Now the card holder will be shown all VAS applications that can be charged at the service terminal and awaiting selection. To do this, the VAS Browsing operation is activated. The cardholder chooses the VAS A application of the implementation class DF_PT or DE_AD.

4. The service terminal searches the VAS-Container with the VAS Application Selection operation to see if the selected VAS application is charged in the card with the PIX _{A and} is already charged in the card. If so, an error report is issued. If not, check if there is another object that is free for the appropriate implementation class in the VAS Container. This is done by searching for a free Record in EF_DIR (eg SEEK). If not available, an error message is issued. If any Record is free, it contains FIDdf_x from DF_X to which no VAS application is loaded.

5. The following free object that is occupied for an A suitable implementation class for VAS A application. In doing so, it first asks the VAS Provider off-line service terminal (eg using the VAS-Provider-SAM) for two keys Klv _A sp and Krvasp and occupies their new VAS application:

• SELECT _FILE <FID _DF7X >

• GEF CHALLENGE • EXTERNAL AUTHENTICATE <K _s0 (random number), KID of K _so >

• UPDATE KEY <KID of K _LVA sp, K _LVAS p>

• UPDATE KEY <KID of K _RVAS p, K _RVA sp>

• GET CHALLENGE • EXTERNAL AUTHENTICATE <K _LVA sp (random number), KID from Klvasp>

• UPDATE RECORD <SFI of EF_INFO of DE_X, data>

• UPDATE RECORD <SFI of EF_INTERNAL of DE_X, data>

• Optional: UPDATE RECORD <SFI of EF_VALUE of DF_X, data>

6. After successfully writing to Efs, the VAS Application Recording <ΡΙΧ _Λ , FIDdf x> operation is performed, which connects DE_X with PIXa and allows SELECT FILE via PIXa (after previous selection with SELECT FILE AIDvas).

The mechanism available with conversion memory can be e.g. use from VAS-Providers who could derive Intra- or Interservices without the necessary DF structures. The card holder then does not have to charge it at the service terminal before using the VAS application. Conversely, it can have a credit note or a credit issued directly at the trading terminal and have it returned at another terminal (withdrawal operation) or a credit note or a credit can only be presented (read). Charging the VAS application of the implementation class EF_TRANSFER is implicitly accomplished by storing the VAS data, respectively. is derived from this operation. Reference is made to the following description of obtaining the implementation class EF_TRANSFER.

The operation of the VAS application recording operation is described below.

When the VAS application is being charged to the VAS-Container, the terminal is an unknown physical location at which DF_X with X = PTi ..., PT _p , ADi, ..., AD ₃ is the VAS application charged, respectively. whether it is charged at all. From the perspective of the card manufacturer, two methods of implementation are possible to be tested separately; particular attention should be paid to the consistency of the ZKA Standards.

First case: EF_DIR access possible

The following conditions must be met:

• Let it be set by default in the EF_DIR card base (eg between DE VAS) in which AIDs are assigned FIDs from DF_X in which VAS applications are currently located.

• This EF_DIR is readable by everyone (AC of READ RECORD: ALW).

• When VAS A with PIXa is loaded from System Operator to free (unused) DF_X, i. The available Elementary Files describe this DF_X (not CREATE FILE!), Then it should be possible to expand the EF_DIR data file by using the UPDATE RECORD to include a PIXa record that references this DF_X with FIDx. AC from UPDATE RECORD should therefore force Kso-key authentication. • When the SELECT FILE <PIXa> command of the previous selection from DF_VAS is delivered to the card, the DF_X to which VAS A is loaded must be directly eligible for selection.

• When the VAS A application, which is loaded into DF_X and the underlying Elementary Files, is to be deleted at the service terminal at the cardholder's request, the corresponding data files are not deleted by DELETE FILÉ, but the recorded data is only overwritten by Dummy values. It should then be possible to delete a PIX _A record (more precisely a PIX _A pair and a reference to DF_X) from the EF_DIR (eg using UPDATE RECORD with a previous external Kso key verification).

• Since the number of DF_X is fixed, the number of EF DIR Records is known.

If this arrangement is feasible, this implies:

• Selecting directly after selecting DFVAS of VAS with SELECT FILE PIX _A is possible.

Second case: Access to EF_DIR is not possible.

When there is no EF_DIR at the base of the card, or there is no read or write access to this EF_DIR - as shown in the above paragraph - it is possible to have an EF_VASDIR data file between DF_VAS where UPDATE RECORD commands (after previous external Kso verification) establish PIX _A relationship with the charged VAS applications to their physical memory location in DE_X. Reading and deleting Records from EF_VASDIR should be described as before.

The VAS record operation is performed as follows:

Application VAS A with PIXa was previously loaded into free DF_X with FID _D f_x · Record number with FIDdf x was recorded by the service terminal.

1. SELECT FILE <AIDvas> (Reporting error when VAS Container is unable to select)

2. GET CHALLENGE

3. EXTERNAL AUTHENTICATE <K _SO (random number), KID of K _so >

4. UPDATE RECORD <SFI of EF_DIR of EF_VAS. Record number with FID _df _x, PIXa, FIDdf_x>

VAS applications of the DF_PT or DF_AD implementation classes can only be deleted at the service terminal (here under the sovereignty of the Operator System) at the card owner's request, VAS applications of the EF_TRANSFER implementation class can be deleted everywhere by everyone. When deleting it is necessary to distinguish VAS applications of the implementation classes DF_PT and DF_AD respectively. EF_TRANSFER implementation classes.

Deletion process of such VAS application for implementation class DF PT and / or DF AD:

• -

1. The cardholder shall insert the VAS card into the service terminal.

2. The service terminal checks whether a VAS Container is available:

• SELECT FILE <AIDvas> (Report error when VAS-Container is not selectable) • READ RECORD <EF_ID> (Read VAS-Container ID)

3. The service terminal presents several options to the card holder for selection. One of them is Deleting the VAS application. This is chosen by the cardholder. All VAS applications of all implementation classes that are loaded in the VAS Container are now shown to the cardholder and the selection is expected. To do this, the operation is activated

Browse VAS applications. The cardholder chooses the VAS A application of implementation class DF_PT or DF_AD with AID _a . The object where the VAS application is charged is called DF_A.

4. After selecting DF_A, the service terminal shall be verified:

• SELECT FILE <PIX _A >

• GET CHALLENGE • EXTERNAL AUTHENTICATE <K _so (random number), KID of K _so >

5. Now the contents of the data files will be deleted from DF_A (for KEY, EF_INTERNAL and EF_VALUE, Klvasp is required, so it will first be deleted from the Operator's System):

• UPDATE KEY <KID of K _LVASP , 00 ... 00>

• UPDATE KEY <KID of Krvasp, 00 ... 00>

• GET CHALLENGE • EXTERNAL AUTHENTICATE <K _LVA sp (random number), KID of K _LVAS p>

• UPDATE RECORD <SFI of EF INFO of DF_A, 00 ... 00>

• UPDATE RECORD <SFI of EF_INTERNAL of DF_A, 00 ... 00>

• UPDATE RECORD <SFI of EF_VALUE of DF_A, 00 ... 00>

6. After successfully writing to EFs with the conclusion from the service terminal, delete the VAS application record from EF DIR:

• SELECT FILE <AID _VA s> (Error report when VAS Container is unable to select) • UPDATE RECORD <SFI of EF_DIR of DF_VAS, Record number with FIDdf.a, 00 ... 00 FID DFA>

PIXA connection to DF_ _A team is resolved, so the Select File with PIXA no longer possible.

Now for EF_TRANSFER implementation class:

According to R&R, the application of the EF_TRANSFER implementation class VAS should be deleted only at the explicit wish of the cardholder at the merchant terminal or at the service terminal (also, if both would be technically possible). Deleting an object from EF_TRANSFER will be especially necessary when the buffer memory has no more free space to store a new object (eg credit note or quantity). The deletion always takes place indirectly via the refill ΤΑΚΕ command. This command records only one object as deleted. This will be released for rewriting by the following additional TRANSFER statement.

To delete this VAS app:

1. The cardholder introduces the VAS card into a terminal that can display the contents of EF_TRANSFER (a special case of a VAS application browsing operation).

2. The terminal tests whether a VAS Container is available:

• SELECT FILE <AIDvas> (error reporting when VAS_ Container is not selectable) • READ RECORD <SFI of EF_ID, 0> (read VAS Container ID)

3. The terminal offers the cardholder more choices. One of them is Deleting the VAS application. The cardholder chooses it. Now, at least the VAS application of the EF_TRANSFER implementation class will be shown to the card holder and pending selection. This is done by a special case of the VAS application browsing operation. The cardholder chooses the implementation class object with a credit or credit card. kvitanciou. This object will receive a Record A number. The card holder confirms the selection.

4. The terminal records the Record with the number A as deleted, while A transmits the random number, its PIX, and the terminal ID with the ΤΑΚΕ command:

• ΤΑΚΕ <A, random number, PIX, terminal ID>

Now, the Record, marked as deleted, is again available to store a new credit note or credit.

The following is a selection process for the VAS application:

When the VAS A application of the implementation classes DF_PT or DF_AD has been charged to the VAS-Container by a VAS application charging operation, it can be selectively selected from the terminal in two stages. First the VAS Container is selected and then the VAS application with its PIXa is selected:

1. SELECT FILE <AIDvas> (error message when VAS-Container is unable to select)

The service terminal can test the authenticity of the VAS-Cointainer. To do this, the service terminal requires the internal verification of the VAS-Container:

• READ RECORD <SFI from EF_ID, 0> (read VAS Container ID) • INTERNAL AUTHENTICATE <random number, KID from K _A ut>

The service terminal tests the response and interrupts in the event of an error (with error message).

2. SELECT FILE <PIXa> (error message if VAS A application is not loaded into VAS Container)

The trading terminal (which does not have KGKaut) can indirectly determine the authenticity of the VAS-Container by testing the authenticity of the VAS A application. Because the VAS application could only be loaded at a service terminal that checked the authenticity of the VAS-Container during the charging process. The authenticity test of the VAS A application may be derived from a trading terminal test to see if the VAS-Container contains a Klvasp or Krvasp key for the VAS A application. check when using:

• INTERNAL AUTHENTICATE <Random number, KID from Krvasp or Klvasp>

In order to test whether the VAS A application is charged in the VAS-Container, it may be difficult to select; an error message from the SELECT FILE may result in an error message that may not be available.

Selection of the VAS application of the implementation class EF_TRANSFER results implicitly from the operation of browsing the VAS application and storing data in the terminal. Since the terminal knows the Record number from each displayed object from EF_TRANSFER, any object can be selected for the Record number for further processing by reference to the Record Number.

Here's how you can browse the VAS application:

The VAS Browsing operation lists all VAS applications of the implementation classes DF_PT, DF_AD, and EF_TRANSFER at the service terminal. Only VAS applications of the EF_TRANSFER implementation class can be displayed on the trading terminal, since there is no access protection for them and optional applications of the DFPT implementation class, respectively. DFAD for which the trading terminal has read rights (possession of Krvasp) ·

The course of such a VAS application:

1. The cardholder loads the VAS card (chip card with a valid VAS Container) into the terminal.

2. The service terminal checks whether a VAS Container is available:

• SELECT FILE <AIDvas> (error message when VAS Container is not selectable) • READ RECORD <SFI of EF_ID, 0> (read VAS Container ID)

Optionally, the validity of the VAS-Container is tested. To do this, the service terminal requires the internal verification of the VAS-Container:

• INTERNAL AUTHENTICATE <random number, KID from K _A ut> The service terminal tests the response and interrupts in the event of an error (with an error message).

3. The service terminal offers the cardholder multiple choices. One of them is Browsing the VAS application. The cardholder chooses.

4. The service terminal shall be verified:

• GET CHALLENGE • EXTERNAL AUTHENTICATE <K _s0 (random number), KID of K _so >

5. For VAS applications of implementation classes DF_PT and DF_AD, individual VAS applications shall be selected sequentially through EF_DIR content-based management, and after external verification by the key K _S o, the content of each EF_INFO (or part of them according to R&R) shall be shown; EF_VALUE:

• For i = 0, ..., nr _D iR - 1 • READ RECORD <SFI of EF_DIR, i>

The response message is PIXa, which is 00..00 when no VAS application is loaded into the corresponding DF. Alternatively to the READ RECORD of EF_DIR, the SEEK command can also be used.

• When PIXa is not equal to 00..00 • SELECTFILE <PIX _A >

• READ RECORD <SFI of EF_INFO, 0>

• show (possibly parts) the reply message • READ RECORD <SFI of EF_VALUE, 0>

• SELECT FILE <AIDvas>

6. For VAS applications of the EF_TRANSFER implementation class, the content (or part thereof) is read according to R&R from EF_TRANSFER of each Record:

• SELECT FILE <AIDvas>

• For i = 0, ..., nrEF_TRANSFER - 1 • READ RECORD <SFI of EF_TRANSFER, i> (the reply message shows the contents of the i-th Record from EF_TRANSFER) • If the content is not empty, it turns out to be interpreted ( eg removed / forfeited).

Browse applications of implementation class DF_PT resp. DF_AD, for which the reader has a trading terminal (possession of Krvasp) results as described - with two deviations: For external verification, instead of K _S o, which only the System Operator has, the Krvasp key is used- When the trading terminal does not have KGKaut, and would nevertheless wish to test the authenticity of VAS applications, the merchant terminal may require verification of (at least one) VAS application instead of internal verification. This will become, as stated, knowledge of the corresponding Krvasp or Klvasp key card ·

For VAS applications of the implementation class EF_TRANSFER, the contents (or part thereof, according to R&R) of the EF_TRANSFER of each Record are listed in the inventory as described above.

Operation The interpretation of VAS operations is analogous to that. The terminal will offer the cardholder a choice of Interpreting VAS Applications. In addition to the data that is visible to the Browse operation, data from EF_INFO and EF_VALUE that need VAS-Provide> rom interpretation (eg, externally encoded data) from EF_INTERNAL (eg, miles passed by Miles & More) may also be shown. However, this is only possible for VAS applications for which the VAS Provider (according to its own ideas) makes available keys suitable for the terminal. The Klvsap key (external verification) is required to read VAS EF_INTERNAL. The corresponding VAS-Provider keys are required for external encoded data within the Elementary Files EF_INFO, EF_INTERN, and EF_VALUE, as well as EF_TRANSFER conversion memory data. The terminal program can easily decide according to the PIX selective VAS application for which applications the data interpretation keys are available.

VAS Transfer operation means transferring all or selected VAS operations of the source card to the destination card at the service terminal. It is a condition that the VAS-Container of the destination card does not have the required VAS applications loaded and all VAS applications on the source card are deleted after transfer. Both can be accomplished by successively using the VAS Application Deletion operation. In addition, the authenticity of the VAS cards must be tested and the target card must have sufficient memory space. The migration operation itself is essentially based on the extension of the VAS Browsing operation, which additionally reads data from EF_INTERNAL and the Klvsap and Krvasp keys, and reusing the VAS Charging operation.

With the VAS data, the VAS Container ID is also transferred to the destination card so that the VAS applications on the destination card behave exactly as they do on the source card. The basis for this is that the VAS-Provider-derived keys are based on the VAS-Container ID, but the keys are copied unchanged. In addition, VASProvider could not change its book keeping in the background system, as it usually identifies VAS cards via the VAS-Container ID. It is imperative that when transmitting the VAS Container ID, make sure that this system remote unique number is deleted on the source card.

In order to be able to read the Elementary Fill EF_INTERNAL and the Klvasp and Krvasp keys in particular, the service terminal will overwrite the Kvasp keys first after the external KAS key validation (analogous to the VAS application clearing operation) and then transfer data from the EF_INTERNAL.

In addition to the VAS applications of the implementation classes DF_PT and DF AD, the EF_TRANSFER data file must be transferred. For this purpose, objects in this implementation class that have not yet been marked as deleted or dropped are removed sequentially, their signature is tested by Ksig_vasc, and transferred to the EF_TRANSFER target card. However, objects will be marked on the destination card as non-captured to remain valid.

Finally, the global VAS-Container data must be transferred, in particular the target card's sequential counter must be set to the source card value.

Here's how VAS data is stored:

There are three possible cases for storing VAS data at a trading terminal, which depend on the type of VAS application.

Get first for DF_PT or DF_AD implementation class

Data from the VAS Provider should be written to the VAS A application of the DF_PT or DF_AD implementation class.

VAS data storage process:

1. The cardholder shall introduce the VAS card into the trading terminal.

2. The merchant terminal tests whether a VAS Container is available:

• SELECT FILE <AIDvas> (Error reporting when VAS Container is not selectable) • READ RECORD <SFI of EF_ID, 0> (read VAS Container ID)

3. The authenticity of the VAS-Container is tested.

When the merchant terminal itself holds the Masterkey KGKaut, it can request internal verification of the VAS-Container:

• INTERNAL AUTHENTICATE <random number, KID from K _A ut>

The trading terminal (which does not have KGKaut) can indirectly determine the authenticity of the VAS-Container by testing the authenticity of the VAS A application. Because the VAS application can only be charged at a service terminal that has checked the authenticity of the VAS-Container during the charging process. The authenticity test of the VAS A application may be derived from a trading terminal test whether the VAS Container contains a Klvasp or Krvasp key for the VAS A application. control:

• SELECT FILE <PIXa> (error message when VAS A is not loaded to VAS Container) • INTERNAL AUTHENTICATE <random number, KID from Krvasp or Klvasp>

The merchant terminal tests the response and interrupts in the event of an error (with an error message).

4. The trading terminal selects the VAS A application, verifies and describes the Elementary Files required to derive the transaction:

• SELECT FILE <PIX _A > (dropped when done in step 3) • GET CHALLENGE • EXTERNAL AUTHENTICATE (Kvasp (random number), KID from Klvasp>

• according to UPDATE RECORD <SFI of EF_INFO of DF_X, data>

• according to UPDATE RECORD <SFI of EF_INTERNAL of DF_X, data>

• according to UPDATE RECORD <SFI of EF_VALUE of DF_X, data>

As a future acquisition for the implementation class EF_TRANSFER

Especially for VAS applications of the implementation class EF_TRANSFER (application class credit note), the VAS-Provider need not occupy any custom DF_X data file structure for its application. As a result, the cardholder does not have to go to the service terminal to load the VAS application before using the VAS credit memo. On the other hand, he can have a credit note or a credit issued directly at the trading terminal and have it returned at another terminal (withdrawal operation) or credit note or credit note. acceptance simply by submitting (reading). By storing the VAS data, this implicitly charges the VAS applications of the EF_TRANSFER implementation class. There is an EF_TRANSFER implementation class for this application class, which consists of individual Art Record objects. Recording to EF TRANSFER is possible only by the TRANSFER command. The trading terminal must be in possession of a valid Kdec depreciation key and have a PIXa of the VAS A application.

VAS data recording process:

1. The cardholder shall introduce the VAS card into the trading terminal.

2. The trading terminal shall test whether the VAS Container is available:

• SELECT FILE <AIDvas> (error message when VAS Container is not selectable) • READ RECORD <SFI of EF_ID, 0> (read VAS Container number)

3. The merchant terminal reads the sequence number that additionally enters the MAC from step 4:

• READ RECORD <SFI of EF_SEQ, 0> (read sequence number)

4. The TRANSFER statement writes into the EF_TRANSFER Record:

• TRANSFER <transaction date, forfeiture date, production code date, PIXa, MAC with Kdec>

5. The merchant terminal may test the TRANSFER command response message to verify that the VAS-Container is genuine (i.e., held by the Kdec common secret) ·

We also refer to the previously described message with the TRANSFER command response.

In conclusion: Obtaining VAS data by deteriorating i

The VAS-Provider can create a claim (eg credit note or acceptance) through an impairment process with a TRANSFER statement, which can be further evaluated by another VAS-Provider. The data from EF_VALUE will be discarded; EF_INFO application of VAS A degraded VAS-Provider. The cardholder will be entitled to an object in EF_TRANSFER.

VAS data recording process:

1. The cardholder shall introduce the VAS card into the trading terminal.

2. The merchant terminal tests whether a VAS Container is available:

• SELECT FILE <AIDvas> (error message when VAS Container is not selectable) • READ RECORD <SFI of EF_ID, 0> (read VAS Container ID)

3. The merchant terminal reads the sequence number that additionally enters the MAC from step 4:

• READ RECORD <SFI of EF_SEQ, 0> (read sequence number)

4. The trading terminal selects the VAS A application:

• SELECT FILE <PIXa> (error message if VAS A application is not loaded into VAS-Container)

5. The trading terminal will use the TRANSFER command to destroy the data from EF_VALUE, respectively. from EF_INFO.

• TRANSFER <data, MAC with K _D ec>

The compilation of the TRANSFER command message has already been described. The terminal is authorized for the deterioration process when it can create a correct signature on the data using the K _D ec key. This is tested by the VAS-Container. Upon success, the VAS Container Record is inserted into EF_TRANSFER and incremented the sequence number.

6. The merchant terminal may test the TRANSFER command response message to verify that the VAS-Container is genuine (i.e., held by the common secret of Kdec) ·

And now the way of devaluing VAS data. There are two types of impairment procedures.

In one, VAS data for VAS applications of the DF_PT or DF_AD implementation class may be degraded by the respective VAS-Provider degradation operation, ie, obtaining the VAS data by degradation. This consumes value, creating a potential claim for another value.

In another, the VAS data from EF_TRANSFER can be taken once with the additional ΤΑΚΕ command. In this case, the claim will be consumed, the data will remain for possible further use (eg a ticket needed to pay for a return ticket) in the transfer field, marked as withdrawn until they are overwritten by other objects as needed.

Progress of VAS data degradation by the ΤΑΚΕ command:

1. The cardholder shall introduce the VAS card into the trading terminal.

2. The trading terminal shall test if a VAS Container is available:

• SELECT FILE <AIDvas> (error message when VAS Container is unable to select) • READ RECORD <SFI of EF_ID, 0> (read VAS Container ID)

3. First, the merchant terminal reads from the EF_TRANSFER objects that are available using a special case of the VAS Browsing operation to determine if there is a search object there. Alternatively, it can be searched for by the SEEK command. The terminal knows successfully the number of the Record you are looking for.

4. The terminal marks Record with number 1 of the Record as deleted, while passing the i, its calculated random number, its PIX and terminal ID with the ΤΑΚΕ command:

• ΤΑΚΕ <i, random number, PIX, terminal ID>

The merchant terminal will use the ΤΑΚΕ command to read data from EF_TRANSFER while marking the data as taken. Embodiment order subsequently treated with a two different cryptograms C and C _2nd

The cryptogram Ci is calculated by the VAS-Container with the key Ksig.vasc. Thus, the applicant of the removed, Ci-signed, object at the Imperator System can prove uniqueness and authenticity.

The uniqueness and authenticity result from the VAS-Provider cryptogram from which the object originally originated (and which has been tested by the card, see TRANSFER) and from the sequential counter transaction by means of the card and the Ci cryptogram during collection.

Cryptogram C ₂ is calculated by the VAS Container with the Kdec key, which derives the VAS Container from KGKdec, PIX and terminal IDs. Knowing the common secret of Kdec, the VAS-Container can directly prove the authenticity of the VAS-Container towards the terminal. Because the TRANSFER command also tests that only genuine credit memos are stored in the right VAS Container. quantity, this may imply the authenticity of the object taken. Since C ₂ is generated indirectly via the sequence number, the bit-taking and the VAS-Container ID, the VAS-Container of the terminal can even prove the uniqueness of the object taken.

Everyone has the right to withdraw by the ΤΑΚΕ order.

At the service terminal, deactivation is also possible. enable password or PIN protection for reading VAS applications of the DF_PT and DF_AD implementation classes. In addition, the PIN of the VAS-Container can be changed by the cardholder by knowing the PIN and by the system by the operator by means of authentication by K _S o excluded. Non-numeric tags or tag strings of any length can also be used as a PIN or password.

Claims (34)

PATENT CLAIMS 1. A smart card that is used to execute transactions where units of monetary value or other non-monetary claims represented by value data are transferred between the cardholder and at least one transaction partner (service provider) or presented to the service provider for verification of claims and which includes memory; in which data is stored for the execution of transactions, characterized in that it includes: a device for charging the card with one or more applications (VAS application), each assigned to a particular service provider, enabling the respective transactions between the cardholder and the service provider assigned to the application to be executed by a non-proprietary transfer memory area (EF-TRANSFER) data storage services representing monetary value units or non-monetary claims exchanged or presented in executing a transaction between different service providers, and a data writing device in response to a Transfer command. A smart card according to claim 1, wherein the charging device comprises: data structure stored in its memory (DF_VAS, VAS-Container), which contains: a sub-structure (DF_PT, DF_AD, VAS application) into which the necessary data (VAS data) can be charged to enable the transaction between the cardholder and the service provider to define a data set containing information about the type or structure of data stored in the sub-structure ( the VAS application), wherein the definition data file further comprises: a data structure (VAS-Container) and / or a license plate identifying the chip card (Container ID); and at least one system key (K 50) that ensures the integrity of the definition data set and / or data structure against modifications. A smart card according to either of claims 1 or 2, further comprising at least one of the following features: a device for charging the data necessary to execute transactions into a sub-structure using at least one system key; a device for writing data to the definition data file for adapting the data of the definition data structure to the data charged to the sub structure; a device for creating another sub-structure into which the data necessary to execute the transaction can be loaded in the card memory; and / or a dynamic memory management device on the card. A smart card according to one of the preceding claims, characterized in that the sub-structures (VAS applications) are independent of each other and are always assigned to a particular service provider, the definition data file being protected by at least one system key (Kso) against modifications and only via This key can be modified, and that the charging of partial structures (VAS applications) can only be performed using the system key contained in the definition data set. A smart card according to one of the preceding claims, characterized in that the definition data set further comprises at least one of the following features: at least one authentication key (K _A ut) for verifying the eligibility of the chip card's relation to the terminal and / or for verifying the eligibility of the terminal's relation to the chip card; at least one signing key (K ₍ i _{g V} asc)) for signing the data taken from the buffer; a generation key (KGKdec) for generating terminal and application-specific keys to check the authorization of the write process and / or to deteriorate the value data; The cardholder verification of the transaction process authorization PIN that the system key (Kso), the authentication key (K _A ut), the signing key (Ksig_vascj and the creation key (KGKdec) are card-specific or data-specific (DF VAS) keys, and the sub-structure (VAS application) shall have at least one of the following: at least one value store (EF_VALUE) for storing value data; at least one internal memory (EF_INTERNAL) for storing internal data related to the sub-structure; at least one information memory (EF_INFO) for storing non-internal data related to the sub-structure; a key memory (EF_KEY) for storing at least one of the keys (Klvasp, Krvaspj) that provide writing and / or reading processes to or from the value memory, and / or internal memory and / or information memory, and that the smart card further comprises: a device for writing and / or reading data into or from the information memory, and that the charging device comprises: a device for writing a key to the key memory when secured by at least one system key. A smart card according to one of the preceding claims, characterized in that the sub-structure comprises at least one of the following features: a key (Klvasp) for checking the write permission of the sub-structure; key (Krvsap) to check the authority to read data from the substructure. A smart card according to any one of the preceding claims, characterized in that the keys stored in the key memory are specific to the respective sub-structure and that at least one sub-structure (VAS application) ensures the execution of transactions through at least one of the specific keys (Klvasp, Krvasp) ), which is specific to the sub-structure concerned and independent of the keys of other sub-structures (VAS applications). In _e A smart card according to any one of the preceding claims, characterized in that the card has a plurality of sub-structures (VAS applications) that are used to execute transactions between a particular service provider and the cardholder, and that the transaction involves writing and / or reading data. in or from the transmission field and / or writing and / or reading in or from the value memory. in A smart card according to any one of the preceding claims, further comprising: a facility for executing transactions both between individual sub-structures (VAS applications) and between the sub-structure and the service provider. A smart card according to any one of the preceding claims, characterized in that the system key (Kso) is known only to the system operator (SO operator system) and is a card-specific and / or data structure (VASContainer) specific key, and the keys contained in the definition data set are individual keys for the cards and / or for the data structure (VAS-Container). A smart card according to any one of the preceding claims, characterized in that the definition data set has one or more of the following features: an identification number (EF_ID) specifying the data structure, a list of sub-structures (EF_DIR) contained in the data structure, the list including sub-structure identifying numbers (VAS applications) identified by the sub-structures charged in the data structure (VASContainer) and part data information structures (VAS-Container) in which partial data structures (VAS applications) are physically stored; Data Structure Version Number (EF_VERSION). A smart card according to any one of the preceding claims, characterized in that it comprises at least one of the following features: an apparatus for performing a collection process (Such) through which the data from the transfer memory is collected and / or destroyed; a device for generating one or more data authenticity features at the time of collection; degradation of data from the transfer memory. A smart card according to any one of the preceding claims, characterized in that the smart card for generating authenticity features comprises: a signing key Ksign_vasc for creating a digital signature about the data taken; an apparatus for generating transaction numbers characterizing a transaction, which is used, inter alia, to create a digital signature. in A smart card according to any preceding claim, wherein the signing key K _S ign_vasc is one of the private keys derived from the private Key Generatig Key, and is accrued to check the signature by the public keys of the service provider. A smart card according to any one of the preceding claims, characterized in that it comprises at least one of the following features: an apparatus for generating, in terms of structure and sub-structure, specific keys (Kdec) by means of a generation key (KGKdec); equipment for verifying correctness and / or securing a transaction using at least one of the following: terminal and specific key structure (Kdec), at least one authentication key (K _A ut), at least one system key (K _so ), at least one specific key structure (Klvasp, Krvasp), signing key (K _S ig_vsac ) PIN, sub-structure license plate, terminal number plate. A smart card according to any preceding claim, wherein the smart card further comprises at least one of the following features: a device for verifying the authorization and / or terminal by means of an authentication key before the reading or writing process starts, a device for performing reading or writing processes which are provided by digital signature and / or encryption. The smart card according to any one of the preceding claims, wherein the smart card further comprises at least one of the following: a device for activating and deactivating the PIN protection device for changing the PIN. IN A smart card according to any one of the preceding claims, characterized in that the data structure according to any one of the preceding claims is independent of the card base and the smart card further comprises: a device for transferring the data structure or parts of the data structure to another card. V V · 19. A smart card, characterized by: an area of memory not belonging to the service provider for writing or reading data to or from the memory area by different service providers to carry monetary value units and / or non-monetary claims represented by value data between different service providers. A terminal for use with a smart card according to any one of claims 1 to 19, wherein the terminal comprises: a device for identifying the chip card data structure (VAS) and identifying the license plate identifying the data structure (Container ID); and that it further includes at least one of the following: a device for reading data from at least one of the sub-structures and / or the definition data file and / or the card memory; a device for writing data to the card's memory; a device for charging the data needed to execute transactions to at least one of the sub-structures (VAS applications) of the card. The terminal of claim 20, further comprising at least one of the following features: an arrangement for executing transactions between the service provider and the card holder, the execution of the transaction comprising at least one of the following steps: writing data to the value memory, writing data to the transfer memory collecting and / or degrading the data from the transfer memory, reading the data from the substructure, reading the data from the transfer memory. A terminal according to either of claims 20 or 21, further comprising: equipment to verify the accuracy and / or secure the transaction using at least one of the following: terminal and partial structure specific key (Kdec), at least one, individual or data structure (DF_VAS) specific, authentication key (K _A ut), at least one, individual or data structure (DF_VAS) specific, system-specific a key (K _S o), at least one, for a sub-structure of a specific key (Klvasp, Kr. VASP) for an individual or data structure card (DF_VAS) of a specific, signing key (Ksig_vasc), for an individual or data structure card (DF_VAS) ) a specific PIN, an application-specific number plate of the sub-structure, a terminal-specific number plate of the terminal. Terminal according to one of Claims 20 to 22, characterized in that the device for writing data to the transfer memory comprises: a device to encode data using a terminal and structure-specific key (Kdec) to prove writing authority. The terminal of any one of claims 20 to 23, further comprising: an apparatus for performing a data acquisition process from the data store through which data from the data store is taken and / or destroyed. The terminal of any one of claims 20 to 24, further comprising at least one of the following features: a device for marking the transfer memory data as removed, a device for marking the transfer memory data as forfeited. Terminal according to one of claims 20 to 25, characterized in that the transaction execution device comprises at least one of the following: the value data modifying device in the sub-structure; equipment for the execution of transactions between various service providers (interservis) at cost or to the benefit of the cardholder. The terminal of any one of claims 20 to 26, further comprising: a device for verifying the authorization of the terminal to the card and / or the card to the terminal using at least one authentication key; a device for securing the transaction by the cardholder via a PIN; device to enable and disable PIN protection. Terminal according to one of Claims 20 to 27, characterized in that it further comprises at least one of the following features: a device for transmitting a specific license plate terminal to a card; a device for transmitting a license plate specifying the sub-structure to the card; an apparatus for verifying the authorization in use of the terminal and for the sub-structure of the specific key and the terminal and for the sub-structure of the specific license plate; equipment for performing reading and writing processes which are provided by digital signature and / or encryption. Terminal according to one of Claims 20 to 28, characterized in that it further comprises at least one of the following features: . partial structure selection device (VAS applications); A device for viewing the partial structure at the terminal; a device for charging a partial structure (VAS application) to the card; a device for charging the plate number of the charged partial structure (VAS application) to the card; an apparatus for deleting a partial structure from a card; an apparatus for substituting the sub-structure with another sub-structure; a device for transferring the sub-structure to another card; a device for interpreting and reading and viewing the partial structure in relation to its function and its associated service provider. · Information. I I A method for executing transactions between a card holder and at least one service provider using a smart card and a terminal, the method comprising one of the following steps: equipment of the data structure stored on the card to which data (VAS data) can be loaded using the card assigned to the service provider necessary to enable the transaction between the cardholder and the service provider to be executed and to write or read data into / from the data structure ) for executing transactions between the service provider and the cardholder, equipping the chip storage area (EF_TRANSFER), not belonging to a data storage service provider representing monetary units or non-monetary claims exchanged or submitted between different service providers, and writing data to the transfer memory or reading data from the transfer memory. The method of claim 30, wherein the method comprises at least one of the following steps: using a smart card according to one of claims 1 to 19; use of a terminal according to one of claims 20 to 29; writing or reading data to / from the value memory or internal memory or information memory of at least one of the sub-structures (VAS applications) The method of claim 30 or 31, further comprising at least one of the following steps: verifying the authorization of the terminal and / or the smart card using at least one key; securing a transaction using a digital signature and / or encoding using at least one key. 33. A method of charging data to a smart card using a terminal, the method comprising at least one of the following steps: charging the data to a partial structure (VAS application) of the card; writing data to the card definition data file, the method comprising at least one of the following steps: using a smart card according to one of claims 1 to 19; use of a terminal according to one of claims 20 to 29. A transaction execution system, characterized by: A smart card according to one of claims 1 to 19 and a terminal according to one of claims 20 to 29.