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

Abstract

Chipcards are used to execute transactions, and other value data representing monetary units or non-monetary entitlements during the transaction are the cardholder and at least one transaction partner (service provider). Or submitted to the service provider for verification of qualifications. This chip card contains a storage where data required to execute transactions is stored. The chip card further includes means for loading one or more card applications (VAS-applications) onto the chip card to allow execution of transactions between the cardholder and one or more service providers.

Description

Chip card and method for its use

The present invention relates to a chip card, a terminal for use with the chip card, and a method for using a chip card system as well as a chip card.

Microprocessor chip cards with payment functions such as electronic purse, ec-cash and credit functions are already in use and depending on their nature Essential prerequisites have been specified by organizations, for example, Zentraler Kreditaus schuβ (ZKA), VISA or EMV (Europay Mastercard VISA), so that they can be used as a means of payment. By way of example, the following are mentioned here:

ZKA, Zentraler Kreditaus schuβ, "interaction specification for the ec-card with chip", 27.10.1995 .;

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

ISO / IEC 7816-4, "information technology-Identification cards-Integrated circuit (s) cards with contacts, Part 4; Interindustry commands for interchange", 01-09-1995;

prEN 1546-1, "Identification card systems-Inter-sector electronic purse, Part 1: Definitions, concepts and structures", 15.03.1995;

prEN 1546-2, "Identification card systems-Inter-sector electronic purse, Part 2: Security architecture", 03.07.1995;

prEN 1546-3, "Identification card systems-Inter-sector electronic purse, Part 3: Data elements and interchanges", 09.12.1994.

An up-to-date overview of chip cards can be found at:

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

Existing chip cards are usually available only for a specific purpose, for example as an electronic money purse or as an electronic identification means. However, applications applied to these chip cards are largely static. They are applied during the manufacture of the chip card and are preserved unchanged from beginning to end of the card's life cycle.

Existing chip cards are limited not only in terms of their variability but also in their functionality. In particular, existing chip cards are fixed in terms of their functionality according to their manufacturing process and no longer change.

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

It is a further object of the present invention to provide a chip card which is still variable in the number and nature of applications which can be carried out by the chip card or by applications and transactions even after the manufacturing process. It will be possible to load additional applications to these chip cards, delete applications from the chip card, and the individual applications will be independent of each other from a data and security-technological point of view. It is defined as and proceeds independently from each other.

The chip card, for example, follows the data security technical requirements according to ISO 7816, and the individual applications of the card will however become independent, in particular from the card platform itself.

It is a further object of this invention to provide a chip card which the user himself can determine, combine or change with the chip card the number and nature of the applications available on his chip card.

In addition, it is an object of the present invention to provide not only interservices (ie applications with additional external relationships involved in external collaborators) by chip card, but also intraservices (ie bookings involved in external collaborators and Both closed loop applications in the sense that no service transfers take place provide a chip card that is both possible and can be performed.

According to an aspect of the present invention, one or more card applications are enabled by the device to enable performance of transactions between the cardholder and one or more service providers by each of the card applications. A device that can be raised is provided.

By this loading, the chip card is configured to provide new functionality, that is, to execute an application that has not been previously opened to it. The uploaded data allows applications to be defined and realized in relation to the card's basic functionality, such as the operating system previously not provided for this card. As a result, the functionality of the card is extended to this particular application by raising this application.

According to an embodiment of the invention, a data structure DF_VAS subdivided into substructures and definition data sets is provided in a chip card according to the invention, which data structure is clearly identified by an encoding which identifies it. And become independent of the card platform. So-called applications can now be placed on substructures, ie the functions and applications of the chip card. As a result, by raising the specific application of the chip card, it becomes possible to perform transactions between the cardholder and the service provider specific to this application. Definition datasets within this data structure contain information about the nature and / or structure of the applications being loaded into the substructure. At least the definition dataset, preferably, however, the entire data structure is secured by at least one system key against modifications and can only be modified by using this key. Instead of a system key, security against modifications is conceived of, for example, a personal identity number (PIN) or other security mechanisms provided by other means as well as security means contributing to such security. Can be done.

With the above structure, it is possible to load various applications into the substructure and also to delete them from the substructure once again so that the card is variable in terms of its functionality or the applications to be performed with the card. The raising and deleting of applications proceeds by writing application specific data and keys into the provided substructure. By preparing for system key and data structure encoding, data structures that allow for multi-functionality are handled independently of the card platform itself and also self-supporting and independent of the card platform for its security structure. Will be dealt with.

Depending on the applications loaded on the substructure, it is possible to perform transactions by the card between the cardholder and the service providers depending on the loaded applications.

Preferably, the chip card further comprises a transfer storage region in which data to be exchanged during execution of transactions is written into or read from it. In the case of reading data from the transmission and storage area, terminal-specific keys must be provided to the terminal, so that individual accesses are handled independently from each other in terms of security.

The individual substructures or applications provided on the card are preferably mutually independent and each is assigned to a particular service provider. They represent data to perform a particular application, that is to say, exclusive or special to this service provider. Depending on the application type and on the service provider, they therefore represent other information, for example specific values, bonus points, account balances, etc., information data relevant to the application. It also contains information data related to service providers. Preferably, however, they contain keys that are particularly specific to applications, whereby access to substructure data is treated as securely possible in a manner independent of other substructures. On the other hand, raising or generating the substructure or the application itself is secured by at least one superimposed system key.

Preferably, prior to the execution of the transaction, mutual authentication should take place between the chip card and the terminal, and an application, which is an application, must be provided with a special authentication key for the substructure.

To execute transactions, data is written to, read from, or executed via a transfer storage area, reserved for a particular VAS-application. First, keys specific to the application are used. In the case mentioned above, a key specific to the application and preferably also to the terminal is used and this key is generated, for example, by a keying key provided on the card and from data specific to the application. The data recorded in the transmission storage area is thus withdrawal by the service provider through the terminal, and this recovery is preferably caused by marking the data stored in the transmission storage area as invalid. If this relates to a service provider that is not specific to the recorded application, this relates to the implementation of so-called interservices, that is, monetary data being exchanged between other service providers for the benefit or cost of the cardholder.

Moreover, for additional security, a PIN or password is provided for verification of the right to carry out the transaction procedure.

The card's variability allows for multiple accommodation of various applications at different times for this card.

The veracity of the data retrieved from the transmission storage area is preferably secured by the use of a signature key or by the use of a digital signature or at least one key. However, in this case, it is particularly advantageous that the recovered data remains in the transport storage area and is simply labeled with the card as complete. In this way, it is still possible to obtain information related to the transaction performed even after the transaction has occurred. In this way and through securing the number of times, it can be proved that the transaction was executed only once.

Moreover, particularly advantageously, data recorded in the transmission and storage area is encoded with an expiry date after which the value is lost. Thus, for example, it is possible to make applications that make available tickets valid only for a particular period of time.

By preferably provided transaction counters, transaction dates, which are value data for their associated transactions, can be clearly determined and identified.

In an advantageous embodiment, the chipcard according to the invention therefore comprises a hierarchical database concept, in which the individual planes of this concept are assigned to different keys against variations which vary at the level of applications relating to the application stored in the database. Secured by each individual application, independent of the rest and secured relative to the rest by a special key owned by it, the entire structure is independent of the card platform itself, and by at least one system key. Secured by the encoding that identifies it. The concept of a transfer storage area allows the exchange of data between cardholders and service providers as well as between other service providers. In addition, reading from or writing to the transfer storage area is similarly secured by keys that are specific to the card and application and additionally also specific to the terminal. The authentication performed prior to each transaction as well as the optional PIN or password enhances the security of the chip card according to the present invention.

In claims 21 to 30, a terminal for use with a chip card according to the invention is defined. This terminal is used for raising or deleting applications, for performing transactions, for viewing of data, as well as for performing additional functions in connection with individual applications and transactions. A process for carrying out transactions between cardholders and service providers is defined in claims 31 to 33, data uploading to a chip card according to the invention is defined in claims 34 and 35, and 36 is a chip card. And the entire system including the terminal.

In the following, the present invention is described with reference to the accompanying drawings through preferred examples.

1 schematically shows a chip card according to the invention,

2 is a schematic diagram of the components of the overall system of this invention;

3 shows the data flow in the overall system,

4 schematically illustrates possible application classes and operations through a transaction model,

5 is a schematic illustration of a security structure of a chip card according to the present invention;

Figure 6 shows the data structure of a typical implementation class of a VAS-container,

7 shows various implementation classes of a VAS-container in accordance with a working example of the present invention,

8 shows a database structure of a VAS container according to a working example of the present invention,

9 schematically shows a database structure of an implementation class DF_PT.

10 schematically shows the database structure of the implementation class DF_AD.

Prior to describing this invention in detail, the various terms used are defined as follows:

VAS: Value Added Services

VAS-card: A VAS-card is a chip card that allows it to participate in value-added services. Like other applications, for example payment applications (ie electronic money wallets), the VAS-card contains a VAS-container.

VAS-Container: A VAS-Container contains data structures, access conditions, keys and (supplement) instructions for managing VAS-applications and for availability of the functionality of VAS-applications.

VAS-Applications: VAS-applications contain VAS data. Access to VAS data is controlled by the VAS-application. The VAS-Provider operates one or more VAS-Applications in a VAS-Container. The utilization of VAS-applications is limited by the application, reading, and processing of VAS data. VAS-applications may take the form of either intraservice or interservice.

VAS-Supplier: The VAS-Supplier is responsible for developing its VAS-applications in accordance with the basic conditions of the system operator and at his discretion and making them available to the cardholders by the system operator and terminals. have. VAS-applications are loaded into the VAS-container of the VAS-card before the VAS-card is able to participate in them.

Intraservice: Intraservice is a type of VAS-application that is used under the monopoly control of individual VAS-providers. Intraservice applications are closed loop applications that ensure that accounting or transfer of execution by external partners does not occur. VAS-application may be either intra- or interservice properties.

Interservices: Interservice applications are intraservice applications that interact with external partners through additional external connections. VAS-application is inherently either intra or inter service.

SO, system operator: The system operator provides VAS-providers and cardholders with a VAS system for use by them.

Issuer: The issuer or card issuer brings the VAS-cards into circulation, including the VAS-containers.

CH, cardholder: A cardholder or cardholder is the person who owns and uses the card (in this case, the VAS-card) to engage in value-added services. This person does not have to be the actual owner of the card.

Service terminal: The service terminal is coordinated by the system operator for VAS-applications. At the service terminal, the cardholder manages VAS-applications in their VAS-cards (uploading, showing, deleting and sending VAS-applications).

Dealer terminal: The dealer terminal owns the payment function and provides VAS functionality in addition. This is where the cardholder uses his VAS-card to pay, on the one hand, and on the other hand, the interests of the VAS.

AID, Application Identifier: The name of the applications that is not longer than 16 bytes for unambiguous distinction of applications without knowledge of the card's database and for the selection of applications from the outside. The AID consists of a 5-byte long Registered Application Provider ID (RID) and optionally a Proprietary identifier registration (PIX) no longer than 11 bytes.

DF: directory file according to ISO 7816.

EF: elementary file according to ISO 7816.

Valid VAS-container: A VAS-container with the ability to authenticate itself with respect to the outside world.

KID, key identifier: The number of the key in the element file that contains the keys.

R & R: Rules and Regulations.

p: The maximum number of objects of the implementation class DF_PT.

a: The maximum number of objects of the implementation class DF_AD.

nr _DIR : Maximum total number of objects: nr _DIR = p + a.

The number of records in EF_DIR is nr _DIR .

nr _{EF_TRANSFER} : Number of records in EF_TRANSFER.

1 schematically shows a chip card according to the invention. In addition to the static and immutable data applied during the manufacturing process, such as the master file (MF) and the monetary wallet (optionally provided), in addition to being provided to the card according to the present invention, an index is provided. Or data structure or database structure (DF_VAS). This is used to accommodate so-called value-added services (VAS), which are additional functionality. Later, in other words, after the card has been manufactured, the card is flexible in terms of the functionality of the card and the transactions to be performed with it, based on the additional functionality indicating the applications to be loaded onto the card. It is variable. The so-called VAS-container (DF_VAS) provided in the chip card according to the present invention allows the chip card's variability and flexibility with respect to its functions, and in addition securely distributes applications housed in the chip card from the card platform. release them so that they are independent of the card platform and transfer them to another card.

New value-added services (value added services, VAS) according to the invention are realized by microprocessor chip cards. The conversion of these additional functionalities takes place by the VAS-container. The VAS-container on the microprocessor chip card constitutes a platform for accommodating VAS-applications. VAS-applications are the individual realizations of special add-ons.

In the case of electronic money wallets, payment by the use of the card (payment function) and VAS-application (additional function) is carried out by separate mechanisms, which, however, do not require a single procedure (for card users or cardholders). procedure).

The microprocessor chip card is extended by the VAS-container to accommodate a variety of independent applications. This creates the deletion and transfer of applications, which are available functions for the application, and these are only used by authorized system operators. The VAS-container is independent of other system components on the microprocessor chip from a data security technical point of view. VAS-containers are fully self-defined and stand alone. A separate security structure is defined for this, so VAS-applications use independent security functions. The security architecture uses card specific keys, which are not specific to the manufacturer and independent of the card platform's identification features.

The VAS-container also uses mechanisms for driving keys specific to the terminal. By this, the VAS-container itself actively checks the authenticity of terminals generating data individually.

In the VAS-container, the VAS-applications are filed and the data is available through the mechanism of the VAS-container, thereby causing control of the associated interface points. The VAS-container allows and controls the secure interchange of data for interservices between partners. The VAS-container actively handles control, i.e. certainty and uniqueness of the transmitted data values.

The advantage of the VAS-container compared to other approaches for multiple application cards is that this concept is independent of the particular card platform. This provides the platform with a security architecture that is independent of specific security mechanisms (eg keys, identification data, PIN, signature procedures).

An additional advantage of the VAS-container concept is that the number of different applications on the card is not strictly preset by the limitations and preconditions at the time of card manufacture or card issuance. Uploading applications to the current card will be freely chosen by the card user and will only be limited by the storage available on the particular card. The number of VAS-applications loaded on a card at any given time depends on the actual use of the card. The cardholder individually collects VAS-applications in his card which need to modify the combination in subsequent steps. VAS-containers allow multifunction cards to be collected and used in a way that card functionality varies over the number and nature of applications during the card's life. Therefore, it is also possible to put applications on a single card that previously required individual special cards and use them together. VAS-applications will also be sent to other cards. Thus, VAS-applications will survive beyond the card's product life and involve the card user during the product life of such applications.

Microprocessor chip cards with additional services are suitable media for distribution and sale where access must protect data. This microprocessor chip card will be used as a means of payment, counter and value storage. This card will provide supplementary services and will be used to control supplementary services by the client itself and at the request of the client after it has been issued in a way that the card adapts. This card also actively controls the certainty of the terminals involved and secures the uniqueness and certainty of the transmitted data.

2 shows a system diagram. This figure shows system components. The system operator makes the system available. VAS-applications will be loaded on service terminals (ST), deleted and transmitted, and further operations include selection, display, interpretation of VAS-applications.

So-called VAS-providers, suppliers of VAS-applications, design their own VAS-applications according to the basic conditions of the system operator and possibly at their own request. Corresponding terminal programs are then checked by digital signature for certainty by termination.

3 shows the dataflow of the system.

VAS-applications are made available for use by the system operator at the cardholder's terminal. VAS-applications must be loaded into the VAS-container of the chip card according to the invention before it is possible to engage them.

In the dealer terminal HT, VAS-applications present on the card are used by application or deletion of VAS-data.

In order to provide VAS functionality to the microprocessor chip card, the VAS container is applied to the card in addition to existing applications (eg payment applications such as electronic money wallets).

The VAS-container uses functions that allow entry, deletion and transfer of VAS-applications. These management functions are used exclusively by the system operator and are secured on the card against external use. The VAS-container has a transport data store that allows the exchange of data between VAS-applications.

Two commands, TRANSFER and TAKE, are used to control the transfer store. The command TRANSFER generates entries in the transfer store using data specific to the individual application. In addition to the useful data, these furthermore have entries such as the date, expiration date and identification data necessary for the control of the processing. By the command TAKE, objects are retrieved from the transfer store and marked as retrieved. Depending on the particular application, objects are marked as being left as valid or invalid. The transmitted data is checked for certainty and uniqueness by the VAS-container.

VAS-applications use VAS-data to make applications available and controlled. Access to the VAS-data is controlled using mechanisms made available to all applications in the VAS-container by the VAS-application. The VAS-Supplier runs one or more VAS-Applications in a VAS-Container. The use of VAS-applications is limited by the loading, reading and processing of VAS-data.

VAS-containers support interservices. Interservices require access to command data between different partners, transmission of service commands and invoicing of services.

Next, services and applications made possible by the chip card according to the invention are listed in the list in connection with the examples.

In each case, the description relates to the realization and function according to the current state of the technology. In the future, the function will be similar to one or more VAS-applications.

First, intraservices are presented.

Example A: customer club

The department store runs a customer club. The customer becomes a club member and receives special club services that are not available to nonmembers under this status. Today, club members identify themselves as club membership documents in the club environment. Club membership documents are prepared at the time of membership, cannot be transferred, and usually have a limited time frame. Special transactions are not executed through the Club Membership Card. In other words, there is no linkage with the customer turnover. In this way, club membership cards are separated from bonus programs where there is a link between identity and gross transaction value.

Analogue: wholesaler membership card, senator card, book club card.

Object: Club membership is demonstrated by application in a VAS-container.

Example B: Bonus System

The customer is credited for each transaction by a bonus claim. Bonus claims are accumulated and converted into monetary benefits when determined by the customer. Award claims are valid and anonymously administered for a fixed period of time or are relevant to the individual. The claim is made from the total transaction amount or number of uses.

Similar: Miles Status, etc.

Object: The points account is managed by the application in the VAS-container.

Example 3: discount

The customer receives a fixed total transaction discount. This discount is granted for each unique transaction. The card does not manage total transaction details. Each transaction is independent.

Eligibility: Entitlement is certified by the VAS-Application.

Example D: Identity document function

The person may be able to prove his eligibility for preset services to third parties by the features in the card. The association between this person and the identification document must be demonstrated for each transaction (photo, PIN, biometrics).

Similar: Internet access, access to home banking, phone card

Subject: Authorization is verified by VAS-application.

Example E: value units

Value units are purchased and consumed by single or multiple uses. With each transaction, its value is reduced by one or more units. User credentials are transferable and limited by use.

Similar: Single Travel Ticket, Multiple Travel Ticket, Contributor Concert Ticket, Squash 10 Point Ticket, Movie Ticket, and Telephone Units.

Target: Transactions are rationalized by the VAS-application.

Example F: Send User Invoice

The user of the service is listed in terms of time, frequency, or quantity and invoiced according to a tariff. The extent to which the service is requested is not known in advance.

Similar: meals voucher, short-term parking ticket.

Subject: By the VAS application, invoice delivery according to the tariff will be allowed. Invoice data appropriate for each particular situation will be stored in the VAS-container.

Example G: Data Records (Mobile Database)

This application allows the transfer of cardholder data to the VAS provider. Transactions are automated by this, but for now they will still be done manually. Currency transfers will not be derived from this data.

Similar: Completion of numbers pool vouchers, shopping lists, cash receipts, telephone registers.

Target: The VAS-Supplier draws data from the card to provide the required services directly (e.g. telephone connection of the total pool voucher, purchases to be collected, electronic completion and record). . This data will be stored on the card either short term or long term.

These examples of intraservices are followed by some examples for interservices.

Interservices occur whenever multiple VAS-providers are involved in the service. It is invariably linked to the data, leaving the environment of one VAS provider. On a date this is done by paper record.

Example A: refund

The department reimburses the customer for the travel ticket of the public transportation company to move to the department store. The customer must present a single travel ticket to the department store. The department store records that the ticket was repaid in the ticket. The department store will again receive part of the reimbursement to the customer from the shipping company.

Subject: The reimbursement process will be performed electronically.

Example B: travel voucher

The department store reimburses the customer for the homeward trip by issuing a redemption ticket when there is a purchase. At the ticket office, the customer receives a ticket from a public transport company or pays for the ticket at low cost. The carrier shall send an invoice to the department store for the redemption ticket.

Subject: Mimicking of mechanisms by VAS-applications involved in electronic accounting between trading and public transport companies.

Example C: Customer Parking

The department store reimburses the customer for part of the parking fee when using a particular parking garage. The parking garage is run by an independent company and receives a monetary payment for each customer credit from the department store.

Object: Imitation of mechanisms by VAS-applications involving electronic accounts between trading and public transport companies.

Example D: Multilateral Bonus Program

A group of trading companies and service providers agree on a joint bonus program.

Eligibility: Each collaborator credits or debits the bonus score for the normal accounting of the card. Accounting for services between collaborators proceeds by an underlying system.

Example E: Recognition of Bonus Scores among Service Providers

Each service provider runs their own bonus program, but treats it as agreeing with other providers on the points they collect. Known examples are agreements on "miles" collected between car rentals and airlines.

Eligibility: Support transfer of bonus points through cards. Each VAS-Supplier initially collects his score on his own, without interference from others. Certain mechanisms are made available for this transfer.

Example F: night taxi

By purchasing travel tickets for public transport companies, a collective taxi (eg after 22:00) is acquired at the same time. For accounting purposes, the taxi company must prove that the travel ticket has been submitted. The use of a taxi is recorded on the ticket to avoid abuse.

Subject: The VAS-Application allows the use, control and accounting of this service.

Next, the configuration of the chip card according to the present invention will be further described.

More specifically, a microprocessor chip card with VAS functionality contains a VAS container.

A VAS-container constitutes an application with the rights it owns and exists either alone or in parallel with other applications on the base card platform. VAS-containers are fully self-limiting and function by themselves. This can be operated without the payment function normally presented on the same card. In particular, an independent security structure is defined for the VAS-container so that VAS-applications can use independent security functions.

Some of the value added services are transactions by the client performed at the terminals of the VAS-providers. The VAS-provider is interested in monitoring these transactions for the purpose of system control or for collecting statistics and other data. In order to optimize and unify data structures in the card, the use of application-specific identifications is not recommended and the use of unambiguous VAS-container IDs available to the entire system is recommended. This number can be used by the VAS-supplier to perform the functions described above and frees the provider from the administrative burden of numbering the systems themselves.

The security architecture of the VAS-container uses this system as an unambiguous ID to obtain special keys on the card. The use of special numbers on the card is possible in principle, but if the VAS-container is to be implemented on other platforms, they are preferably not used, since in some cases they use conflicting numbering systems.

The VAS-container ID is issued by the system operator and filled in by the card issuer when generating the VAS-container. This is destroyed by deleting the VAS-container and thereby removed from the system. The VAS-container is considered deleted if it does not contain VAS-applications and the VAS-container ID is removed.

During the entire transfer of the VAS-container from the old card to the new card, the VAS-container ID is jointly transmitted with the VAS-applications. This transfer corresponds to the transfer of the VAS-container from the old card to the new card. After this procedure, the old card no longer contains the VAS-container. The VAS-containers existing on the new card are overwritten and deleted during this operation. Since the VAS-Container ID is transferred from the old card to the new card, no modification of the reference numbers is necessary for the VAS-provider's basic systems.

Individual VAS-applications may be transferred under the control of a prevailing VAS-provider between two different VAS-containers. During this function, the association between the VAS-Container ID and the VAS-Application will be changed and recorded in the VAS-Provider's base system.

VAS-containers do not contain personalized features. VAS-applications will contain private data, but its scope will be kept to a minimum for data protection reasons and for improved memory usage operations. VAS-applications, if necessary, will store data relating to the individual in the base system and create an association with the card by the VAS-container ID.

The support of interservices constitutes an important feature of the VAS-container. Interservices require access to common data, transfer of service claims, and accounting of services among other partners. The VAS-container will make these things possible and nevertheless ensure the security of applications in intraservices.

So-called intraservice VAS-applications operate under exclusive control of the VAS-provider. The VAS-provider defines the security of the application independently from any external entity. An external party can transform the VAS-data without the proliferation of the key.

For effective implementation of interservices, collaborators must have access to shared data. Solidarity access to data is realized by multi-level security mechanisms.

The first phase of solidarity access is carried out exclusively by public transport fields. VAS-providers will exchange data by these fields without mutual understanding of the necessary applications and keys. Terminals only require appropriate keys to put data into the transmission fields but do not require a key to read them. Anyone will read without restrictions. The data interchange will proceed in both directions between the VAS-Supplier and the Partner, if each has its key available to put the data. The transport data will be generated from the VAS provider's intraservice VAS application, or vice versa, the VAS provider will put data from the transport field into its intraservice VAS application.

The second step is the cancellation of the value units represented by the VAS-data. The VAS provider introduces value units into the VAS data by means of a special key to insert the data. Value units will be consumed by interservice partners who can use unit erasing keys obtained from the VAS-provider with comprehensive responsibility. At this stage, collaborators with different rights influence each other with non-public VAS-data.

The third step is direct data entry access to VAS-data by all involved interservice partners. This method requires a reasonable degree of trust among the parties, since the VAS-data can be modified without limitation.

The transport field serves as a connection between VAS-applications. Data in the transport field is generated in the VAS-container by the VAS-applications. The data will also go directly into the transport field if the person does not have his own VAS application running in the VAS container.

A transmission field is available in principle for all applications, but entries will only be made by a person who has been qualified for it (by key). Only in terms of the regulations, or R & R, will the recipients qualified for it remove the data from the transmission field. The receiver checks for the existence of the transmission data assigned to him and withdraws them for processing in the system he owns.

In order to prevent manipulation of transmitted data in public interchanges, generators introduce certainty features and VAS-containers introduce sequence numbers. The unity of the transmission report is secured by these factors and the origin of this data is verified.

If necessary, the receiver of the transmitted data is provided by the generator with means for performing a certainty check. If this is not desired, the acceptance of the data will occur with good credit, in which case it is only possible to check certainty features when the accounting takes place in the VAS-provider's underlying system.

Recovery of data from the transmission field is possible only once, without loss of certainty features. When retrieved, the data is displayed and left (as a copy) in the transfer field. This allows proof of the transmission procedure for a certain period of time, even after the recovery of this data.

The data in the transmission field carries the expiration date. Expired data will be overwritten when required by arbitrary applications. This data in the transmission field will be marked as frequency and freed for immediate overwriting. Since the transfer store must nevertheless be completely filled before the transfer data set expires, the cardholder must delete entries that are no longer needed at the service terminal.

Three operations are defined for modeling VAS-applications. These operations act on the VAS-data. Loading and deleting applications are the functions of the VAS-container and are not considered in the following paragraphs.

Purchasing: In general, the purchase of a qualification for services in the VAS-data of a VAS-application and the filing of its proof.

Canceling: Generally redemption of qualifications with all or no consumption or partial consumption of VAS-data of an application. This procedure generates an electronic receipt which is sent to the transmission field. This receipt provides the appropriate expiration date to be removed from the transport store on that date.

Withdrawing: The retrieval of an electronic receipt from a transmission field, usually for further processing (eg a basic system). Copies of receipts will remain and serve as evidence of "expiration".

"Acquiring" of VAS-data proceeds solely through the individual VAS-provider. The "expiration" of the VAS-data only occurs by "purchasing" this or through the VAS-provider, which has occurred by an interservice partner authorized for it by the VAS-provider. Interservices that do not have equal rights to access VAS-data cause triggers of the "transition" state transition by the collaborators. The electronic receipt retrieved by it will be revealed through the basic system of the system operator and the VAS-supplier. "Buy" and "Clear" will occur in a single step.

VAS-applications with common features will be broken down into classes. These classes form the basis for data structures in the VAS-container. During the implementation of his application, the VAS-provider chooses the application class.

In this situation, the following application classes are defined:

Score database

·ticket

Identification document

Refund ticket

Database

The score database represents the application class in which an account of score values is managed. For and from the score account, the values will be credited and retrieved. Crediting of values proceeds through the VAS provider and the database puts a new account balance in it. Debiting of the values proceeds by an "erase" operation in which the electronic receipt is taken as evidence in the transmission store. Access to two functions is by two different access keys.

The ticket has a value field in it, which indicates that the application class is to be cleared and consumed either once or several times. Crediting values in an application is executed only once.

The identity document indicates the application class for which the VAS-data receives evidence of entitlement. Evidence is not generally erased by use, but after predetermined criteria, for example after a lapse of time, this is invalid. Depending on the definition of the application, the authenticity of the identification document (eg nearby parking permits) or the act of submitting this document is documented (eg joint taxi travel using monthly tickets: generation of electronic receipts by card. Receipts are submitted by the taxi company to the public transport company and counted proportionately). Optionally, the use of the identification document will be documented by electronic receipts in the card's transfer storage.

The voucher marks the class of application where the service entitlement (usually for a short period) is placed in the card's interim store. These vouchers are stored exclusively in the transport store of the VAS container. Applications using the redemption voucher differ from the applications that generally occur. Retrieval of the redemption ticket from the transfer storage is possible only once and is documented by the card. The certainty feature generated by the VAS-container will be used during accounting in the base system.

Data storage involves storing data in the VAS container so that the VAS-provider provides additional services to the client (e.g., final menus, full numbers of final numbers, service preferences, and proposal lists in fast food restaurants). List application classes. This data is for information only and does not represent a claim for services against the VAS-provider. Access to this data is controlled by the VAS provider.

Each application class is characterized by a typical user cycle. The following table describes the number of times the three above defined actions apply to VAS-data of an application class. (Note: "Buy" does not mean "Upload of Application" and "Recovery" means " "Deleting an application").

TABLE 1

In the case of ^*** in the application class "data storage" in Table 1 above, no qualification is obtained, and the application simply puts data into the application.

4 illustrates operations through the application classes and transaction model listed above.

Next, the security structure of the chip card according to the present invention will be described in more detail. To ensure security, the following keys are defined:

TABLE 2

The security structure is based on the product life of the VAS-container or VAS-applications and layered according to the responsibilities of those involved. A schematic illustration for explanation will be apparent from FIG. 1.

In the following, some explanation is provided for the structure of the VAS-containers as well as the applications applied thereto.

Special supplementary orders to the VAS as well as the VAS-container are issued to the card by the issuer in solidarity with other non-VAS applications, or eventually at the service terminal by the VAS provider authorized into the existing card platform at the service terminal. Are integrated.

For the second possibility, the following mechanism will find application: The system operator agrees on the issuer and the temporary key (K _SO ^* ). The issuer opens the card with his key known only to him, opens the files in the VAS-container and writes K _SO ^* into DF_VAS in particular. The system operator replaces the key (K _SO ^* ) with his own key (K _SO ) at some later time (e.g. the moment the card enters and comes into contact with the service terminal for the first time) and this key (K _SO ) You will only be known to yourself.

The system operator can either insert additional data, for example KGK _DEC , or create or delete files for VAS-applications on his own platform with dynamic memory management. This ensures that after the initial use of the VAS-card, the issuer no longer has access to the VAS-container and that only the system operator has access to the VAS-container. Because of the absence of any common data structures and data interchange with other applications, the security structure of the VAS-container is thus independent of other applications present on the card platform.

In a particular embodiment of this invention, however, use is made of the first possibility: the issuer is required to authorize the VAS-cards with the VAS-container with all the keys in relation to the instructions of the system operator.

The VAS-container consists of a preset data structure, preset access conditions (Acs) and some global data. Global data contains, inter alia, the key (K _SO ) for loading or deleting VAS-applications. This key, known only to the system operator, ensures that only authorized VAS-applications can be loaded. For this purpose, the card requires external authentication via _KSO by the system operator.

Whenever a cardholder wishes to post a VAS-application to a service terminal, the appropriate VAS-provider accordingly instructs the system operator to do this for him. When the VAS application is loaded into the VAS container, the VAS provider sends the keys K _LVASP and K _RVASP to the system operator, who puts them into the application. The key K _LVASP allows the VAS provider to protect the application's data against the write access and, in addition, the internal data against the read access. For this purpose, the card requires external authentication of the VAS-provider based on K _LVASP . In other words, the card actively checks the authenticity of the terminal. After successful execution of this function, the terminal is allowed write access to the VAS-application and read access to the VAS-data of this application. Internal certification, ie checking the VAS application (and thereby the card) for certainty via the dealer terminal, takes place optionally. If a VAS-application is used by the cardholder, this internal VAS-data will be written to the application or modified at the optional terminals with access to the key K _LVASP . The "buy" function is supported by the UPDATE RECORD command, where external authentication by key K _LVASP will _precede it.

Read access to non-internal data of VAS-applications is allowed only if previous external authentication takes place by K _RVASP or by K _SO or by correct entry of a PIN or password by the system operator. PIN / password protected access is provided to allow the cardholder to look closely at the data at the terminal or in a wallet. The cardholder will choose either active or inactive the PIN / password for reading the value or status data from the service terminal.

Global data of the VAS-container is associated with a key K _{SIG_VASC} for signing data extracted from the transport field. By signature, the intactness of such transaction data will be checked whenever they need to be protected and transmitted against manipulation between interservice partners for mutual accounting. In addition to signatures introduced selectively through _interservice partners, a signature based on K _{SIG_VASC} and a transaction counter managed by the VAS-container are added for the sets of data that the card issues through a "recovery" operation. On the one hand the reading of the transmission field is allowed by any one, but on the other hand it will only occur when the signature of the card via K _{SIG_VASC} is called for the "recovery" operation (this can only happen once). As such, any unauthorized dual accounting for repatriation rights is recognized. Each interservice collaborator may have certainty and uniqueness with respect to the retrieval rights that have been acknowledged by the system operator. In addition, the authenticity of the VAS-container can be verified by checking the signature of the system operator.

If the card platform uses asymmetrical key procedures, it is also possible to use a private (secret) key in the card for the purpose of signing as K _{SIG_VASC} or to derive this key from the private keying key. . VAS-providers use public (non-secret) keys in such cases to check the signatures themselves without asking the system operator for their opinion.

Part of the data of the VAS-container is a global key generation key (KGK _DEC ) (with the ability to generate an access key (K _DEC ) for all terminals of all VAS-providers for the authorization check for the "erase" operation). The key derivation and checking of the problem will be formed again later). The erasure of monetary value data is not subject to the same security measures as raising or purchasing qualifications. For this purpose, it is sufficient to use global keys instead of special keys for applications. This global key is initially switched by derivation to the application key and then by the derivation that is restarted to the terminal key. The VAS-provider merely informs the application of the global key of a particular derivation to generate the owned terminal key. This is briefly described in the following:

We mark mac (k, d) with the DES-key calculation by DES and the authentication code for message d. This message corresponds to the coding itself unless it is longer than 8 bytes (previous ICV = 0). We denote the calculation of mac (k, d) with the subsequent adaptation of parity bits with macp (k, d). The resulting k '= macp (k, d) is once again a valid DES key.

The calculation of terminal keys specific to the application proceeds as follows:

1. Each card stores the key KGK _DEC , which is the same for all cards and is kept secret by the system operator. The system operator provides this key to be personalized into the card.

From this key all other VAS-application and terminal keys can be derived.

2. The VAS-Supplier wishes to introduce _VAS- Application A as AID _A = RID _VAS , PIX _A. The system operator is now the application-specific key from the key (KGK _DEC ) and PIX

KGK _{DEC, PIX} = macp (KGK _DEC , PIX _A )

Calculate and pass this key to the VAS provider.

3. The VAS-Supplier derives, with their terminal IDs, their special keys from KGK _{DEC, PIX} for all terminals that the TRANSFER command is supposed to be applied to VAS-Application A:

KDEC = macp (KGK _{DEC, PIX} , Terminal ID) =

macp (macp (KGK _DEC , PIX _A ), Terminal ID)

The VAS-provider stores these keys in its terminals. If the VAS-provider does not operate the terminals normally, he generates these keys and distributes them to the operators of the terminals.

4. Only the VAS-card executes the TRANSFER command, which executes the cryptogram C generated by the terminal formed by the special data of the message in the transport store. The card itself recognizes the KGK _DEC and obtains not only the terminal ID but also the PIX from the terminal in addition to the user data and password C (or alternatively the card itself knows the PIX, and therefore also the description of the command TRANSFER). Get to know). The card can now calculate the password C 'from the following user data:

mac (macp (macp (KGK _DEC , PIX), Terminal ID), Data) =

mac (macp (KGK _{DEC, pix} , terminal ID), data) =

= mac (K _DEC , data) =

= C '

The card now compares the cipher C 'calculated by itself with the cipher C calculated by the terminal. If they are different, termination and fault reporting of the transaction occurs. If congruence, the VAS-card will execute the TRANSFER command.

Several security measures are consistent with other configurations of service terminals or dealer terminals (individually uploading or purchasing) and simple dealer terminals (if canceling). In order to perform the "erase" operation, the terminal must authenticate itself to the card by having knowledge of K _DEC . If the key K _DEC is compromised, the attacker can simply perform the function of this single terminal. However, this procedure is recorded on the card. Documentation contains unambiguous sequence numbers, erasures, and terminal IDs. VAS-applications use the security services of a VAS-container to organize access to VAS-data. Execution of functions specific to VAS is limited to the parties authorized by the definition of access rights.

In general, for each VAS-application, the officially accessible data areas of the responsible VAS-provider (eg in case of reading of values by wallet) and private data areas are available and the latter Protect against access by persons (eg internal management data).

Given that ISO 7816-4 does not provide separate access protection for individual records of element files (EF), each file is intended to display different sights for VAS-applications. It is necessary to use multiple files, which contain records.

Thus, for the application classes, score storage, ticket, identification document and data storage, differentiated access protection will take place by subdividing the VAS-data into four element files as shown in FIG.

The four element files contain the following data or are protected in the following way:

TABLE 3

This structure of the element files (EF) supports the same distinct permissions for all application classes.

Keep in mind that application classes are now combined into a single implementation class that lowers the number and size of element files so that the waste of storage due to other space requirements for applications is minimized. The application classes Score Store and Ticket require the same resources, EF_KEY, EF_INFO, EF_INTERNAL, EF_VALUE, and are therefore bound to the implementation class "DF_PT". In the case of application classes, identity documents and data storage, the element files, EF_KEY and EF_INFO, are suffices and are therefore bound to the implementation class "DF_AD". In view of the number, there are p objects of the implementation class DF_PT and a objects of the implementation class DF_AD in the VAS-application of application classes, score storage and tickets, on which the identification document and data store can be loaded individually. do.

Obviously this uses the transfer field, the implementation class, for the transfer right, which is an application class, which should provide public read access for all VAS-participants for the purpose of linked data interchange. Write access is indirectly possible by the application of the TRANSFER command, which presupposes the exclusive signature to K _DEC . This implementation class consists of exactly one entry in EF_TRANSFER, the element file belonging to the global data of the VAS-container. The objects of this class are the records in this file. We also deal with this implementation class as "EF_TRANSFER".

The implementation classes shown in FIG. 7 exist in the VAS-container. These implementation classes form the storage model of the VAS-container.

Storage models can be made available in two ways. Its nature depends on the card platform:

Fixed partitioning of storage areas for VAS-containers:

For the implementation classes DF_PT and DF_AD, the maximum number of objects, p or a, is fixed by the issuer, if possible, and carded by the issuer using the CREATE FILE commands. Objects are represented by DF_PT and DF_AD, respectively. VAS-applications will later be loaded on free objects, ie objects not occupied by other VAS-applications. In the case of loading or deleting VAS-applications, only UPDATE RECORD commands are needed.

Thus, the issuer fixes the number of possible objects in the two implementation classes according to the requirements he owns. However, these will be different from the cardholder's actual VAS-user pattern. Subdivision will be maintained under the card's entire product life. VAS-applications are loaded on objects belonging to the appropriate implementation class. Thus, for example, a VAS-application representing an identity document may also be accommodated in an object of implementation class DF_PT if (no more) objects of the implementation class DF-AD are not available. The assignment of a VAS-application to an object is caused by putting a triple (PAS of the VAS-application, the FID of the loaded object, the clear text name of the application) into EF_DIR, the global database of the VAS-container. . The transfer of applications corresponds to the migration from this tripel's EF_DIR and the destructive read of memory loaded by the applications (by the UPDATE RECORD command).

This variant is used with card platforms that do not support the dynamic generation or deletion of DF / EF structures.

Dynamic configuration of objects of the implementation class:

For each VAS-application to be loaded, the files are set by the CREATE FILE commands as required by the underlying implementation. When deleting a VAS-application, the occupied DF / EF is completely removed from the card and the storage space is freed. The minimum number of objects of the implementation classes here is not explicitly determined by the issuer and only depends on the storage capacity of the card available.

This variant presupposes dynamic database management by the card operating system.

In the following work, we will start with the first variant because the second places high demands on the available card platforms. However, if dynamic memory management is available and it is ensured that more storage can be saved by the dynamic configuration of objects than corresponding to the cost of administration, existing concepts will be employed and more for cardholders. Provides a lot of adaptability.

Next, the data structures and instructions are presented by means that the VAS-container and functionality of the VAS-client card can be executed relative to other system components. In addition, the VAS-applications are in a typical business situation describing the individual interactions between the VAS-container and the terminal.

The following preconditions apply to the implementation:

Each card makes the same data and command interface available to the dealer terminal, regardless of platform. Thus, the required instructions are clearly described in their encoding.

• Service terminals can recognize the card platform. Functionality is therefore achieved by platform specific commands. Thus, these transactions are partially written informally. The way this feature is provided is left to the card manufacturer.

In Fig. 7, various implementation classes of the VAS-container are schematically shown in this context. 8 schematically shows the data structure of the VAS-container, and FIG. 9 shows the data structure of the implementation class DF_AD.

Access to files in the VAS-container is explicitly limited by the following access conditions:

TABLE 4

In this relationship, AC has the following meanings:

ALW = command access to the database is always allowed.

NEV (nothing) = no command access to the database is allowed.

• K _SO = External authentication of the system operator through the key (K _SO ) must occur before access.

K _LVASP = external authentication of the VAS-provider via the key (K _LVASP ) must occur before access.

K _RVASP = External authentication of the terminal authorized by the VAS-Supplier before access must occur via the key (K _RVASP ).

PIN = The correct PIN must be entered by the cardholder prior to access and must be clearly transmitted to the card by the command VERIFY.

PIN or K _RVASP or K _SO = The correct PIN must be _entered by the cardholder prior to access or external authentication must be done by the VAS provider using K _RVASP or by the system operator using K _SO .

In this context, Or-linking of access rights, as indicated above, is generally not provided in the card operating system. If applicable, this will involve special implementation costs (an alternative: special READ instruction with implicitly fixed security attributes).

The data fields in the records of the element files are distinguished according to the following formats: ASCII, Binary, BCD, Date, Format string.

Data elements of type "formatstring" contain VAS-data in a packaged presentation that can be displayed for a cardholder at the terminal.

For optimal data storage usage, clear text and binary data are mixed and treated as displayable through formatting macros.

All the element files (EF) of the VAS-container are defined as linearly formatted EF databases (linear fixed record files) with records of constant length in accordance with ISO 7816-4.

The element file EF_DIR of DF_VAS consists of nr _DIR records. For each VAS-application loaded on a VAS-container, its proprietary identifier extension (PIX) and its physical repository (the FID of DF_X loaded into it) are fixed to the record in EF_DIR. . PIX, for example, as a code number, identifies the application and service provider to which the application is assigned.

Entries in EF_DIR are dynamically set at the service terminal of the system operator. Records without entries are set to an empty TLV object '61'.

When loading a VAS-application, a free storage area for the appropriate implementation class is found, certain VAS-data is put in there and finally a new record is generated in EF_DIR.

When deleting an application, a blank TLV object should be written to EF_DIR accordingly.

The element file EF_VERSION of DF_VAS consists of a record containing the version number of the VAS container.

The version number will be used at the terminal to distinguish between different VAS-container variants and / or other software versions.

The element file EF_SEQ of DF_VAS consists of a record containing the number of the following transport field entries.

The sequence number is read by the supplementary instruction TRANSFER. This command generates a record in the transmission field EF_TRANSFER, in which the sequence number from EF_SEQ is transmitted therein. To ensure that each record from the transmission field is recovered only once and in solidarity with the order TAKE, which records this number by signing with a sequence number, only one collection of (original) vouchers or receipts is guaranteed. do.

Next, transfer storage is handled in more detail.

The transfer store is set up in the VAS-container and contains nr _EF-TRANSFER records. Entries in the records of these files contain the transfer data generated by the TRANSFER command. The data exchanged between the VAS-applications as well as the storage of the VAS-data of the class Voucher are carried out via transfer storage.

The transfer save can be read without restriction, but the write access is possible only through the special commands TRANSFER and TAKE to VAS.

Raising datafields by the TRANSFER command is done by the 'most recently used' algorithm on the card. The oldest record in the database can be determined by searching for the lowest value of the first two bytes of the record.

Data fields are marked as retrieved and / or removed by the command "TAKE" in the transfer storage. In each case, deleting data in the transfer storage occurs by overwriting with new data.

Each record in the transport store contains, for example, an expiration date, terminal-ID, PIX, sequence number, and optionally additional data.

Each element file in the list DF_X (where X = PT ₁ , ..., PT _p , AD _1, ..., AD _a ) contains records containing expiration dates as well as general VAS-data for VAS-applications. Include. For example, the nature of the ticket (single or multiple tickets) or boarding locality will be put here. However, EF_INF0 must contain at least one clear text name of the application being read for VAS-viewing operations. Sensitive data must first be protected by the appropriate foreign key algorithms by the VAS-provider.

If K _SO or if external authentication happened using K _RVASP or cardholder to put the correct PIN in the case of this active PIN- protection, EF is able to read.

Each element file EF_INTERNAL in records DF_X (where X = PT ₁ , ..., PT _p , AD _1, ..., AD _a ) is the internal VAS provider of the VAS provider associated with its raised VAS application. It consists of records that will contain data. None of the cardholder or any other VAS-provider can read this internal data.

Each element file EF_VALUE in records DF_X (where X = PT ₁ , ..., PT _p , AD _1, ..., AD _a ) contains a record that will contain the integer value field of the VAS-data. This EF can be read if external authentication occurs with K _SO or K _RVASP or if the cardholder enters the correct PIN in the context of PIN-protection becoming active.

The following keyfields are used by the VAS-container or by the VAS-application. Next, we will start with pure DES-encoding, i.e., all the keys of the VAS-container are DES-keys and encoded in 8 bytes (including parity bits).

In the VAS-container and in the VAS-applications the following keys will be referred to as referenced by their KID (key identifier):

TABLE 5

Each key is connected to a fault action counter. It lists failed authentication attempts with this key and blocks further use once the limit of entering this count is reached.

Within the VAS-application the following keys will be referenced by their KIDs.

TABLE 6

Each key is connected to a fault action counter. This records failed authentications, attempts with this key, and blocks any further use once the limit on entering this counter is reached.

The VAS-Container contains a personal identification number or password (PIN). This is used to identify the cardholder through the VERIFY command. The PIN is connected to a fault action count and this counter records each fault input and closes the PIN-comparison as soon as the limit is reached. This blockade will be restarted by the system operator using the appropriate administrative commands. The combined action counter is restarted once the correct PIN is entered.

The following parameters exist for the VAS-container and will be chosen by the card issuer according to the space available on the card platform and its personal desires:

Maximum number of objects of implementation class DF_PT p

= Maximum number of VAS-applications in the ticket vault and ticket, which are application classes that can be loaded simultaneously in the VAS-container;

Maximum number of objects of implementation class DF_AD a

= Maximum number of VAS-applications in the identity store and data store, which are application classes that can be loaded simultaneously into the VAS-container;

Maximum number of objects nr _DIR : nr _DIR = p + a

The number of records in EF_DIR is nr _DIR ;

Number of records of _{EF_TRANSFER} nr _{EF_TRANSFER}

The storage requirements for data in the described element files are as follows:

byte

Global data of VAS-container EF_ID 4

EF_DIR 9 * (p + a)

EF_VERSION 1

EF_SEQ 2

Global keys, PIN 64 + 2

Transmission field: EF_TRANSFER 46 * nr _{EF_TRANSFER}

Ownership data of VAS-supplier EF_KEY (p + a) * 32

EF_INFOR (p + a) * 62

EF_INTERNAL p * 10

EF_VALUE p * 3

If we choose the following values for the parameters p, a, and nr _{EF_TRANSFER} , for example, the following minimum storage requirements occur for the VAS-container (without storage requirements for supplementary instructions): do:

Parameters Storage Requirements

p = 8, a = 3, nr _{EF_TRANSFER} = 15 2030 bytes

P = 10, a = 5, nr _{EF_TRANSFER} = 20 2758 bytes

The maximum storage requirement will probably be about 10% higher than the minimum storage requirement.

Next, the instructions of the chip card according to the present invention will be dealt with in more detail.

The READ RECORD command is used to read data from linear element files. The card supplies the contents of the records in response. EF is referenced by the short file identifier (SFI).

Status code '9000' signals the successful execution of a command, but any other code is considered an error.

The UPDATE RECORD command is used to put data into a linear EF. Command messages contain references to EFs, records and data.

The card's response contains a status code. Status code '9000' signals the successful ending of a command. Other status codes indicate an error.

The GET CHALLENGE command requires a random number from the card. This random number is used in conjunction with dynamic authentication in EXTERNAL AUTHENTICATE.

The card's response message contains an 8-byte long random number and status code. Status code '9000' indicates successful execution of the command. Any other status codes indicate an error.

The command EXTERNAL AUTHENTICATE allows authentication of the terminal to the card. EXTERNAL AUTHENTICATE is used in the context of VAS-applications for authentication of system operators and VAS-providers. EXTERNAL AUTHENTICATE transmits a password into the card, which must be generated by encryption of random numbers by the terminal prior to transmission. The card compares the cipher with the reference value of the random number having it calculated using the same procedure. If both values are the same, the card internally knows that access condition authentication has occurred for this key. If the comparison is considered negative, the card issues the status as "unauthorized" and reduces the internal fault action counter. Once this counter reaches the value '0', execution of any additional EXTERNAL, AUTHENTICATE is blocked with an "authenticated" state.

The card's response message contains the status code. Successful execution of command and authentication of the terminal in relation to the card is indicated by status code '9000'. Any other status codes indicate an error.

The command INTERNAL AUTHENTICATE is used to check the authenticity of the VAS container by the terminal. The card calculates the password through the reference data derived from the terminal for this purpose. The terminal in turn forms a password and compares it to the value on the card. In the same situation, the terminal may assume certainty of the VAS-container.

The response of the card contains the status code and password for the execution of the command. Successful execution of the command is indicated by status code '9000'. Any other status codes indicate an error.

The VERIFY command is used to verify the cardholder's PIN. This command sends unencrypted PIN data to the card, where the card is compared with the stored reference value. If the entered and stored values are the same, the access conditions "PIN" are considered to be on demand.

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

The TRANSFER command generates an entry in the transfer store. Three operating modes are defined for this command:

1. Generation of an entry in a transmission field by a reduction of values in the EF-VALUE field of a ticket or score store application of class.

2. Generation of entries in the transmission field by receipt creation in the application of identity documents of class.

3. Generation of an entry in a transmission field by generating a redemption ticket in the application of a redemption ticket of class

The operating mode is automatically selected by the card. If the command is executed in the selected application-DF, the presence of EF_VALUE is first checked. If EF_VALUE is present, the card executes this command in mode 1, otherwise in mode 2. If no Application-DF is selected in the VAS-container, mode 3 is used.

The terminal, when called for the TRANSFER command, supplies the following data to the card:

ㆍ Current date

Expiration date for entries in the transfer field

Identification of the terminal generating this entry;

ㆍ User data for transmission field

ㆍ PIX of VAS application (mode 3 only)

Number of units to be deducted (mode 1 only)

MAC associated with the aforementioned data, sequential number and VAS-container number

The card executes the following sequence once the TRANSFER command is called:

1. Search for free entry in the transport store. (The following list gives priority in reverse order and existing entries in that priority are overwritten next: "entries marked as removed", "entries marked as recovered" and "expired expiration date").

2. Attach PIX to terminal data in modes 1 and 2.

3. Attach the sequence number to the data from step 2.

4. Attach the VAS-Container ID to the data from Step 3.

5. encoding a PIX under KGK KGK _DEC induce _{DEC, PIX.}

6. Deriving K _DEC by encoding terminal ID under KGK _{DEC, PIX} .

7. Generate MAC over the data in step 4.

8. Comparison of MAC from step 7 with MAC of terminal. If the values differ, the card interrupts the function and reduces the fault action counter by KGK _DEC .

9. For mode 1: The application tests the value field EF_VALUE of the register loaded into it. If insufficient units appear in this field, the card interrupts the function at this point. Otherwise the value field of the application is reduced by this amount.

10. Assembly of command messages.

11. Increase the contents of EF_SEQ by 1.

The command message contains, for example, the expiration date, terminal ID, transaction data, fields for operating mode (eg PIX in mode 3), as well as fields containing passwords.

The cipher is calculated using, for example, the key K _DEC , which is data formed by the MAC containing the transaction data and the terminal-ID:

The response message of TRANSFER, when successful, has an 8-byte long data field and a 2-byte status code '9000'. Reply messages with status codes different from '9000' are interpreted as error codes. The data field of the reply message contains the K _DEC encoded code of the command message (ie, instead of the internal authentication using the K _AUT ) in an error-free situation (ie, especially when the command message has been corrected). Is executed internally by the VAS-container.

The command TAKE is used to retrieve objects from the implementation class EF_TRANSFER. Technically, executing the command TAKE means reading a record that should be marked from store EF_TRANSFER, which record is kept in the store until storage is required for a new entry, and this set of data is retrieved ( withdrawn). Technically, anyone can use the command TAKE to retrieve a set of data, but according to R & R, only the VAS-supplier for which this set of data is intended can do this.

For the removal procedure, the following will be taken for granted: The VAS-Supplier is the person who wishes to remove the voucher or receipt, and retrieves the appropriate set of data (eg by command SEEK or by explicit reading of each record) from the transport. The data in this set will be read anyway and its contents will be checked.

The display of the data set in response is therefore not necessary. In addition, the number of records can be assumed to be known.

The command TAKE provides the following modes:

Eliminate with simultaneous annotation that data is invalid

Removal without comment. This data remains valid.

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

PIX in the command indicates an application that removes data. This is different from PIX of the data set being removed and is exclusively used to derive the K _DEC of the dealer terminal resulting in the removal.

Response message from the card is VAS- container ID and a command message with a K _{SIG_VASC} associated with the data of the records in the report transmitted password fields in C _1, the password having a K terminal of the _EDC, which results in the removal by C ₁ C ₂ and a command Contains a random number taken from the message. In addition, the response message contains a status code. The key K _DEC is derived as described further above. Certainty is implicitly demonstrated by the VAS-container in terms of cryptography via K _DEC . The evidence of certainty and uniqueness is computed by the cryptographic C, which can be verified by the system operator (since C is formed by the sequence number, the removal bit of the transport field record, and the VAS-container ID).

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

It is assumed that the SO (system operator) requires one AID _VAS in accordance with IDO / IEC 7816-5. More specifically, he requires a 5 byte long RID _VAS for the _VAS- system.

The AID _VAS in the list DF_VAS is understood as follows: RID _{VAS ·} = AID _VAS. PIX _{DF_VAS}

For each VAS-Application A, a 3-byte long PIX _A returns the former AID _A = AID _VAS. Issued in accordance with R & R to ensure unambiguous identification within the VAS-container via PIX _A. After selecting DF_VAS, the list containing VAS-Application A will be selected using SELECT FILE <PIX _A >.

UPDATE KEY (KID, K) indicates a command that depends on the card platform where the key is replaced by the new value K using the key identifier ID. The VAS-application from one of the implementation classes DF_PT or DF_AD (corresponding to the application classes score store, ticket, identification document or database) is not available to the cardholder at the dealer's terminal before it is used by the appropriate VAS-provider service. It must be loaded into the VAS container at the terminal. In principle, it is also possible to load one or more VAS-applications into the VAS-container if the card issuer is directed by the VAS-provider and the system operator SO is already mounted. This raising process constitutes the special case described here.

The raising procedure for VAS-applications is:

1. The cardholder inserts the VAS card into the service terminal.

2. The service terminal checks that the VAS container exists:

SELECT FILE <AID _VAS > (error report if _VAS- container is not selectable)

• SFI, O> of READ RECORD <EF_ID (display of VAS container number) Optionally, the validity of the VAS container is checked. To this end, the service terminal requires internal authentication of the VAS-container:

ㆍ INTERNAL AUTHENTICATE <random number, KID of K _AUT >

The service terminal checks the response and terminates the procedure if there is an error (with an error display).

3. The service terminal offers the cardholder a choice of options. One of these represents the raising of the VAS-application. This is chosen by the cardholder. All VAS-applications that can be loaded on the service terminal are now displayed on the cardholder and await the selection. For this purpose, the display operation of the VAS-applications becomes active. The cardholder selects the VAS-application A of the implementation classes DF_PT or DF_AD.

4. The service terminal checks the VAS-container through the VAS-application's operation selection as to whether the selected VAS-application with PIX _A has already been loaded on the card. If positive, an error signal is displayed. If not, a check is made to see if an object of the implementation class conforming to A is still available in the VAS-container. This is done by searching for free records in the VAS-container (eg using the command SEEK). If no one is available, an error signal is displayed. If the record is empty, it contains the FID _{DF_X} of _{DF_X} without the VAS-application loaded into it.

5. Following this, the VAS-application is loaded on the free object of the implementation class appropriate for A. For this purpose, the service terminal first requests offline to the VAS-provider's two keys K _LVASP and K _RVASP (eg via the VAS-provider SAM) and assigns them to a new application:

SELECT FILE <FID _{DF_X} >

ㆍ GET CHALLENGE

ㆍ EXTERNAL, AUTHENTICATE <K _SO (random number), K _SO KID>

ㆍ UPDATE KEY <K _LVASP KID, K _LVASP >

ㆍ UPDATE KEY <K _RVASP KID, K _RVASP >

ㆍ GET CHALLENGE

ㆍ EXTERNAL AUTHENTICATE <K _LVASP (random number), K _LVASP KID>

ㆍ UPDATE RECORD <SFI of EF_INFO of DF_X, Data>

ㆍ UPDATE RECORD <SFI, Data of EF_INTERNAL of DF_X>

Option (initialling): UPDATE RECORD <SFI of EF_INFO of DF_X, Data>

6. After a successful entry in the EFs, the service terminal executes the VAS-Application <PIX _A , FID _{DF_X} > operation, which connects DF_X to PIX _A (after priority selection via SELECT FILE AID _VAS ). _A allows SELECT FILE.

The mechanism made available by the transport store will be used, for example, by VAS-providers who wish to implement intraservices or interservices without proprietary DF-structures. The cardholder needs to put this on the service terminal first, especially before using this VAS-application. On the other hand, he will issue a voucher or receipt directly to himself at the dealer's terminal and have a redemption from another terminal (by removing operation) or simply present a voucher or receipt (by reading). The loading of the VAS-application of the implementation class EF_TRANSFER is therefore implicitly realized by the loading of VAS-data or by this operation. In this context, the criterion is realized by the implementation of the implementation class EF_TRANSFER or is caused by such an operation. In this relationship, a reference is made to the description of the purchase of the implementation class EF_TRANSFER below.

Next, the progress of the loading operation of the VAS-application is explained.

If the VAS-application is loaded into the VAS-container, the terminal is physically located at DF_X where X = PT ₁ , ..., PT _p , AD ₁ , ..., AD _a , indicating that the VAS-application has been loaded. Or do not know how it was raised. From the cardmaker's point of view, two possible implementation modes are possible and these modes are checked separately, and in this situation, consistency with the ZKA standard should be observed in particular.

Initial situation: Access to EF_DIR is possible.

The following requirements must be met:

• EF_DIR (in DF-VAS) exists in a standard way on the card platform, where the VAS-applications currently have FIDs of the DF_X and AIDs associated (eg under DF-VAS).

• This EF-DIR can be read by anyone (AC: ALW in READ RECORD).

If the VAS-Application A with PIX _A is loaded by the system operator into the free DF_X, that is, if the entry is made with the existing element files DF_X ((with no CREATE FILE!)), The database EF_DIR is changed by the entry PIX _A , FIX. _a via can be expanded through the UPDATE RECORD referencing this DF_X. of AC UPDATE RECORD must be reinforced by the external authentication key K thus _SO.

• If the command SELECT FILE <PIX _A > after the priority selection of DF_VAS is sent to the card, the DF_X loaded in it must be directly selectable.

If a VAS-application loaded on DF_X and its auxiliary element files is deleted at the cardholder's request at the service terminal, the corresponding databases are not deleted by the DELETE FILE, but the inserted data is simply dummy values. It is written superimposed on. It will thus be possible to delete the entry PIX _A (more specifically, the reference to a set of PIX _A and DF_X) from EF_DIF (eg by previous external authentication and UPDATE RECORD via key K _SO ).

Since the number of DF_X is fixed, the number of records in EF_DIR is known.

If this approach is feasible, the results are as follows:

• Direct selection of VAS-applications using SELECT FILE PIX _A is possible following selection of DF_VAS.

Second situation: Access to EF_DIR is not available.

If a specific card platform EF_DIR can not or read access to the EF_DIR as described above in the previous paragraph or impossible letter used, the preparation (provision) is, (after external authentication ahead with K _SO) by the system operator Created under EF_VAS for the database EF_VASDIR for a connection made to the VAS-application loaded into PIX _A to the physical storage of DF_X, caused by explicit UPDATE RECORD commands. Reading and deleting records from EF_VASDIR will be possible as previously described.

Execution of the action entry VAS-application proceeds as follows:

The VAS-Application A with PIX _A was previously loaded into the FID _{DF_X} into the free DF_X. The number of records with FID _{DF_X} was known by the service terminal.

SELECT FILE <AID _VAS > (Error display if the _VAS container cannot select)

2. GET CHALLENGE

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

4. UPDATE RECORD <Record number with SFI, FID _{DF_X} , PIX _A , FID _{DF_X} of _{EF_DIR} of _{DF_VAS} >

VAS-applications in the implementation class DF_PT or DF_AD can only be deleted at the request of the cardholder at the service terminal (under the control of the system operator), and VAS-applications in the implementation class EF_TRANSFER can be deleted by anyone. When deleting, it is necessary to distinguish the implementation class EF_TRANSFER between the VAS-applications of each of the implementation classes DF_PT and DF-AD.

Deleting this VAS-application for the implementation class DF_PT or DF_AD proceeds as follows:

1. The cardholder inserts the VAS card into the service terminal.

2. The service terminal checks that the VAS container exists:

SELECT FILE <AID _VAS > (Error display if _VAS container is not selectable)

READ RECORD <EF_ID> (Display of VAS Container ID)

3. The service terminal offers the cardholder a choice of options. One of them is VAS-application deletion. This is chosen by the cardholder. All VAS-applications of all implementation classes loaded on the VAS-container are now displayed to the cardholder and await their selection. For this purpose, the VAS-applications display operation becomes active. The cardholder selects VAS-Application A of the implementation class DF_PT or DF_AD as AID _A. The object loaded with the VAS-application is assumed to be the indicated DF_A.

4. After selecting DF_A, the service terminal authenticates itself:

ㆍ SELECT FILE <PIX _A >

ㆍ GET CHALLENGE

ㆍ EXTERNAL AUTHENTICATE <K _SO (random number), K _SO KID>

5. The contents of the files in DF_A are now deleted (K _LVASP is _required for EF_KEY, EF_INTERNAL and EF_VALUE, which is why the former is first deleted by the system administrator):

ㆍ UPDATE KEY <K _LVASP KID, "00 ... 00">

ㆍ UPDATE KEY <KID of K _RVASP , "00 ... 00">

ㆍ GET CHALLENGE

ㆍ EXTERANL AUTHENTICATE <K _LVASP (random number), K _LVASP KID>

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 successful entries into the EFs, the service terminal then causes the entry of the VAS-application to be deleted from the EF_DIR.

SELECT FILE <AID _VAS > (Error display if _VAS container is not selectable)

And UPDATE RECORD <DF_VAS EF_DIR of SFI, numbers written in _{FID DF_A, "00 ... 00"} , FID DF_A>

Correlated (interlinkage) of PIX _A for DF_A is canceled (undo) the SELECT FILE with the PIX _A no longer possible.

Next is the implementation class EF_TRANSFER:

The VAS-application of the implementation class EF_TRANSFER can only be removed from the dealer or service terminal at the explicit request of the cardholder (although it can technically be executed by either), depending on the R & R. Deleting an object from EF_TRANSFER will be necessary, especially if the transport store has no more space to store the new object (eg voucher or receipt). Deletion always proceeds indirectly via the supplementary command TAKE. This command simply marks the object as removed. Thereafter it is free to be overridden by a subsequent supplementary instruction TRANSFER.

The deletion of this VAS-application proceeds as follows:

1. The cardholder inserts the VAS-card into a terminal capable of displaying the contents of EF_TRANSFERF (special case of the display behavior of VAS-applications).

2. The terminal checks whether a VAS container exists:

• SELECT FILE <AID _VAS > (error display if the _VAS container is not selectable).

READ RECORD <SFI of EF_ID, 0> (Display of VAS-Container ID)

3. The terminal makes available to the cardholder a choice of options. One of them is VAS-application deletion. This is chosen by the cardholder. At least the VAS-applications of the implementation class EF_TRANSFER are now displayed to the cardholder and await the selection. This is caused by showing VAS-responses, which is a special case of operation. The cardholder selects the object from the implementation class containing the voucher or receipt. This object has record number A. The cardholder activates the selection.

4. The terminal marks the record with record number A as removed, and sends A, the random number calculated by it, its PIX, and the terminal ID using the command TAKE:

TAKE <A, Random Number, PIX, Terminal ID>

Records marked as removed are now available again for a new voucher or receipt.

The selection of the VAS-application proceeds as follows:

When the VAS-Application A of the implementation class DF_PT or DF_AD is loaded into the VAS-container by the VAS-Application Upload operation, it may be selected by the terminal in two steps. First, a VAS-container is selected, and then a VAS-application containing its PIX ₄ is selected:

SELECT FILE <AID _VAS > (error display if _VAS- container is not selectable)

The service terminal can check the authenticity of the VAS container. For that purpose, the service terminal requires internal authentication of the VAS-container:

READ RECORD <SFI of EF_ID, 0> (Display of VAS container ID)

ㆍ INTERNAL AUTHENTICATE <random number, KID of K _AUT >

The service terminal checks the response and if there is an error, stops the operation (with an error indication).

2. SELECT FILE <PIX _A > (error if VAS-Application A is not loaded in VAS-container)

The dealer terminal (without the available KGK _AUT ) will indirectly determine the authenticity of the VAS-container by checking the authenticity of the VAS-Application A. This is because the VAS application could only be loaded on the service terminal that checked the authenticity of the VAS container during the loading procedure. The validation of the VAS-Application A may be returned to the dealer terminal to test whether the VAS-Container contains the key K _LVASP or K _RVASP for the VAS-Application A. This can be checked by the dealer terminal, for example:

ㆍ INTERNAL AUTHENTICATE <Random number, KID of K _RVASP or K _LVASP >

The VAS-Application A may be arbitrarily selected to test whether it is loaded into the VAS-container. Based on the error indication in the response message of the SELECT FILE, it may be determined that the VAS-Application A does not exist.

The selection of the VAS-application of the implementation class EF_TRANSFER is implicitly caused by the operation of storing data and displaying the VAS-applications at the terminal. Since the terminal knows the record number of each displayed object from EF_TRANSFER, it is possible to select any desired object for further processing with respect to the record number.

The execution of the VAS-application display proceeds as follows:

The operation of showing VAS-applications lists all VAS-applications of implementation classes DF_PT, DF_AD and EF_TRANSFER in the service terminal. Only VAS-applications of the implementation class EF_TRANSFER can be displayed on the dealer terminal because of the absence of access protection to it, and optionally the implementation class DF_PT with reader rights (owned by K _RVASP ) or Applications of DF_AD may be displayed.

Such VAS-application proceeds as follows:

1. The cardholder inserts a VAS-card (a chip card with a valid VAS-container) into the terminal.

2. The service terminal tests whether the VAS container exists:

SELECT FILE <AID _VAS > (error indicating that the _VAS container is not selectable)

READ RECORD <SFI of EF_ID, 0> (Display of VAS container ID)

Optionally, the validity of the VAS container is checked. For this purpose, the service terminal requires internal authentication of the VAS-container:

ㆍ INTERNAL AUTHENTICATE <random number, KID of K _AUT >

The service terminal checks the response and, in the case of an error, stops the procedure (with an error indication).

3. The service terminal offers the cardholder a choice of options. One of these options is the display of VAS-applications. This is chosen by the cardholder.

4. The service terminal authenticates itself:

ㆍ GET CHALLENGE

ㆍ EXTERNAL AUTHENTICATE <K _SO (random number), K _SO KID>

5. For VAS-applications of implementation classes DF_PT and DF_AD, individual VAS-applications are selected and controlled sequentially by the contents of EF_DIR, and not only EF_VALUE but also EF_VALUE after external authentication with key K _SO . According to R & R, the contents of part of it) are displayed:

For i = 0, ..., nr _DIR -1

ㆍ READ RECORD <SFI, i> of EF_DIR

If the VAS application is not loaded on the corresponding DF in the response message, PIX _A is displayed as "00..00". As an alternative to READ RECORD from EF_DIR it would also be possible to use the SEEK command.

• If PIX _A is not equal to "00..00"

ㆍ SELECT FILE <PIX _A >

ㆍ READ RECORD <SFI of EF_INFO, 0>

ㆍ Display of response message (optionally only part)

ㆍ READ RECORD <SFI of EF_VALUE, 0>

ㆍ SELECT FILE <AID _VAS >

6. For the VAS-applications of the implementation class EF_TRANSFER, the contents of EF_TRANSFER (or part thereof according to R & R) of each record are displayed:

ㆍ SELECT FILE <AID _VAS >

When i = 0, ..., nr _{EF_TRANSFER} -1

ㆍ READ RECORD <SFI, i> of EF_TRANSFER

(The response message displays the contents of the i-th records of EF_TRANSFER.)

If the content is not empty, the content is displayed in interpreted form (eg acquired / expired).

The viewing of the applications of the implementation class DF_PT or DF_AD so that the dealer terminal has viewing rights (owned by K _RVASP ) proceeds as described, subject to both changes: key for external authentication. K _RVASP is used instead of K _{SO which is} only available to system operators. If the dealer terminal does not have a KGK _AUT available and never wants to check the authenticity of VAS-applications, the dealer terminal may require certification of (at least one) VAS-application instead of internal certification. This proceeds as described by the recognition of the card of the corresponding K _RVASP or K _LVASP key.

For VAS-applications of the implementation class EF_TRANSFER, the contents of EF_TRANSFER (or part thereof according to R & R) of each record are listed sequentially as previously described.

The interpretation operation of the VAS-applications proceeds similarly. For this purpose, the terminal offers the cardholder an option of interpretation of the VAS-applications for selection. In addition to the data displayed due to the display operation, data from EF_INFO and EF_VALUE (such as externally encoded data) and data from EF_INTERNAL (such as Miles & More) that require interpretation by the VAS-provider and Together it is also possible to indicate miles from previous years). However, this is only possible for VAS-applications for the VAS-provider (in its own choice) to make appropriate keys available at the terminal. Key K _LVASP (External Authentication) is required to read the EF_INTERANL of the VAS application. For externally coded data in the element files of EF_INFO, EF_INTERN and EF_VALUE as well as the transfer storage EF_TRANSFER, the appropriate keys of the VAS-provider are required. The terminal program can be easily identified with the help of the selected VAS-application PIX, for which application keys can be used to interpret the data.

The transfer operation of the VAS-applications indicates the transfer of all or selected VAS-operations of the source card on the target card at the service terminal. This is a precondition that VAS-applications are not loaded in the VAS-container of the target card, and all VAS-applications are deleted from the source card after the transfer. Both can be achieved by successive applications of the operation of deleting the VAS-application. In addition, the authenticity of the VAS-card should be checked and the target card should provide adequate storage capacity. The sender action is additionally based essentially on the extended application of the VAS-applications to read data and keys K _LVASP and K _RVASP from EP_INTERNAL, and the repeated application of the raise operation of the VAS-application. In conjunction with the VAS-data, the VAS-container ID is also sent to the target card in order to ensure that the VAS-applications of the target card are executed exactly as they did on the source card. The reason for this is that the keys derived from the VAS-provider are supported by the VAS-container ID, the keys, but replicated without modification. Moreover, the VAS-provider does not want to change its accounting in the base system because it usually identifies the VAS-cards by the VAS-container ID. During the transmission of the VAS-Container ID, it is essential to ensure that this number unique to the system is deleted from the source card.

In order to make the element file EF_INTERANL and keys K _LVASP and K _RVASP specially readable, the service terminal first superimposes the key K _LVASP after external authentication by key K _SO (as in the operation of deleting a VAS-application). After writing, data is overwritten from EP_INTERNAL after K _LVASP 's renewal authentication.

In addition to the VAS-applications of the implementation classes DF_PT and DF_AD, the file EF_TRANSFER must be overwritten. For this purpose, the move operation is used continuously to transfer objects of this implementation class that have not yet been marked as migrated or expired, checking their signature by K _{SIG_VASC} , and allowing the transfer of the target card to EF_TRANSFER. Run On the other hand, on the target card, the objects are marked as not transferred and they will continue to be valid.

Finally, the entire data of the VAS-container must be transmitted. In particular, the sequence number of the target card should be adjusted to the value of the source card.

The procedure for filling in VAS-data is described in the following:

There are three cases where the VAS data can be filled in at the dealer terminal, depending on the nature of the VAS application.

First, purchase in the case of implementation class DF_PT or DF-AD

The VAS-Provider is to write data into the VAS-Application A of the implementation class DF_PT or DF-AD.

The entry of the VAS-data proceeds as follows:

1. The cardholder inserts the VAS card into the dealer's terminal.

2. The dealer terminal checks whether the VAS container exists:

SELECT FILE <AID _VAS > (error indicating that the _VAS container is not selectable)

READ RECORD <SFI of EF_ID, 0> (Display of VAS container ID)

3. The authenticity of the VAS container is checked.

If the dealer terminal itself owns the master key KGK _AUT , it may require an internal certification of the VAS container.

ㆍ INTERNAL AUTHENTICATE <random number, KID of K _AUT >

The dealer terminal (no KGK _AUT is available) may indirectly check the authenticity of the VAS container by checking the authenticity of the VAS-Application A. This is because the VAS application could only be loaded at the service terminal that checked the authenticity of the VAS container during the load. The validation of the VAS-Application A may be referred back to the test at the dealer's terminal to determine whether the VAS-Container contains the key K _LVASP or the Key K _RVASP for the VAS-Application A. This can be checked for example by the dealer terminal as follows:

ㆍ SELECT FILE <PIX _A > (Error display if VAS-Application A is not loaded on the VAS container)

ㆍ INTERNAL AUTHENTICATE <Random number, KID of K _RVASP or K _LVASP >

The dealer terminal checks the response and, in the case of an error, stops the procedure (with an error indication).

4. The dealer terminal selects VAS-Application A, authenticates itself, and describes the necessary element files to execute the transaction.

SELECT FILE <PIX _A > (if removed in step 3, it is removed)

ㆍ GET CHALLENGE

ㆍ EXTERNAL AUTHENTICATE <K _LVASP (random number), K _LVASP KID>

ㆍ Optional item: UPDATE RECORD <SFI of EF_INFO of DF_X, Data>

ㆍ Optional item: UPDATE RECORD <SFI of EF_INTERNAL of DF_X, Data>

ㆍ Optional item: UPDATE RECORD <SFI of EF_VALUE of DF_X, Data>

The purchase now follows the implementation class EF_TRANSFER.

In particular, for VAS-applications (application class Voucher) of implementation class EF_TRANSFER, the VAS-provider does not need to occupy the proprietary file structure DF_X for its application. The result is that the cardholder does not have to proceed to the service terminal to raise the VAS application before using the VAS application certificate. Rather, he issues a redemption ticket or receipt directly at the dealer's terminal, and at the other terminal they are reimburse (or by a previous operation) or simply show (read) the redemption ticket or receipt. Thus, writing of VAS-data results in implicit loading of VAS-applications of the implementation class EF_TRANSFER. For this application class there is an implementation class EF_TRANSFER consisting of the individual objects of the type record. Entry in EF_TRANSFER is possible exclusively by the instruction TRANSFER. The dealer terminal must possess a valid eraser K _DEC for that purpose and make PIX _A of VAS-Application A available.

The entry of the VAS-data proceeds as follows:

1. The cardholder inserts the VAS card into the dealer's terminal.

2. The dealer terminal checks whether the VAS container exists:

ㆍ SELECT FILE <AID _VAS > (error display if _VAS- container is not selectable)

READ RECORD <SFI of EF_ID, 0> (Display of VAS container number)

3. The dealer terminal reads the sequence number additionally entering the MAC from step 4:

ㆍ READ RECORD <SFI of EF_SEQ, 0> (Sequential number display)

4. The command TRANSFER causes the record to be written to EF_TRANSFER:

TRANSFER <transaction date, expiration date, generator code, data, MAC by PIX _A , K _DEC >

5. dealer terminal can be checked by whether there must be a VAS- container that is, owned by a joint secret _{K DEC (joint secret K DEC)} ] to check the precision of the response message TRANSFER command. In this context, reference is made to the response message following the command TRANSFER described above.

Finally, purchase of VAS-data by erasing

The VAS-provider may generate entitlements (such as vouchers or receipts) for further use by other VAS-providers by means of an erase value using the command TRANSFER in the transfer field of EF_TRANSFER. The data is erased from EF_VALUE or EF_INFO of the VAS-Application A of the VAS-Supplier to have an erase effect. The cardholder obtains rights in the form of an object in EF_TRANSFER.

The entry of the VAS-data proceeds as follows:

1. The cardholder inserts the VAS card into the dealer's terminal.

2. The dealer terminal checks whether the VAS container exists:

ㆍ SELECT FILE <AID _VAS > (error display if _VAS- container is not selectable)

READ RECORD <SFI of EF_ID, 0> (Display of VAS container ID)

3. The dealer terminal reads the sequence number which additionally enters the MAC in the process of step 4:

ㆍ READ RECORD <SFI of EF_SEQ, 0> (Sequential number display)

4. The dealer terminal selects VAS Application A:

ㆍ SELECT FILE <PIX _A > (Error display if VAS-Application A is not loaded in VAS-Container)

5. Dealer terminal can be the following cases, so use command TRANSFER to erase data from EF_VALUE or EF_INFO.

TRANSFER <data, MAC by K _DEC >

The composition of the command message of TRANSFER has already been described. Eligibility to perform an erase is obtained by the terminal if K _DEC can make an accurate signature on the data. This signature is incremented by the VAS-container. If successful, the record is set to EF_TRANSFER by the VAS-container and the sequence number is incremented.

6. The dealer's terminal can check whether the VAS-container has been certified (ie owns the common secret K _DEC) by checking the response message of the TRANSFER command.

The procedure for erasing VAS-data will now be covered. There are two kinds of erase procedures:

On the other hand, the VAS-data for the VAS-applications of the implementation class DF_PT or DF_AD can be erased by the appropriate VAS-provider due to the erase operation, ie the purchase of the VAS-data due to the erasure. In that way, values are destroyed, thereby creating potential qualifications for different values.

On the other hand, VAS-data can be fetched once from EF_TRANSFER only by a supplementary command TAKE. In that case, the entitlement is destroyed, the data is displayed as it was removed until it was invalidated by other objects when required, and subsequent use (such as redeemed tickets will be returned trip). Is still required in the transmission field).

The deletion of the VAS_data by the command TAKE proceeds as follows:

1. The cardholder inserts the VAS card into the dealer's terminal.

2. The dealer terminal checks whether the VAS container is available.

SELECT FILE <AID _VAS > (error display if _VAS- container is not selectable)

READ RECORD <SFI of EF_ID, 0> (display of VAS-container ID)

3. The dealer terminal first displays the objects available from EF_TRANSFER using the special case of the VAS_Show Applications operation to determine whether the requested object is available. As another alternative, the command SEEK can be used to retrieve a sample. If successful, the terminal recognizes the number i of the retrieved record.

4. The terminal displays the record to show the record number i in transmitting i, the random number calculated by it, its PIX and the terminal ID together with the command TAKE.

TAKE <i, random number, PIX, terminal ID>

The dealer end uses the command TAKE to read the data from EF_TRANSFER and identify the data as it was retrieved at the same time. In addition, the execution of the instruction results in the generation of two different cryptograms C ₁ and C ₂ .

The cipher C ₁ is calculated by the VAS-container using the key K _SIG-VASC . In this way, the producer of a migrated object signed with C ₁ can obtain evidence of uniqueness and certainty from the system operator. The uniqueness and certainty of the transaction stems from the VAS-provider's cipher at which the object was originally originated (checked by the card, see also TRANSFER), and the maintenance of the sequential counter for the transaction as well as cipher C1 by the card at the time of withdrawal .

The cipher C ₂ is calculated by the VAS-container using the key KGK _DEC , which is derived by the VAS-container from the KGK _DEC , PIX and the terminal ID. By recognizing the annual close K _DEC , the VAS-container can prove its certainty directly to the terminal. Due to the fact that only the original transfer tickets or receipts during the TRANSFER command are stored in the authenticated VAS-container, the certainty of the retrieved object can also be determined. Since C ₂ is indirectly formed by the sequence number, the recovery bit, and the VAS-container ID, the VAS-container can further prove to the terminal the uniqueness of the recovered object.

Anyone has the right to retrieve using the command TAKE.

Furthermore, at the service terminal, inactivity or activity of each of the password or PIN-protection is possible for reading the VAS-applications of the implementation classes DF_PT and DF_AD. In addition, the PIN of the VAS-container can be changed by the cardholder who recognizes the PIN and can be recovered by the system operator by external authentication by KSO. Non-numeric symbols or symbol sequences of the selection length can also be used as a PIN or password.

Claims (36)

Other value data representing monetary units or non-monetary entitlements are transferred between the cardholder and at least one transaction partner (service provider) or for verification of qualifications. A chip card for executing transactions submitted to a service provider, the chip card having a storage device for storing data required for executing transactions, And a means for placing on the card one or more card applications (VAS-applications) each of which allows execution of transactions between the cardholder and one or more service providers. The method of claim 1 wherein the means for loading comprises a data structure (DF_VAS, VAS-container), the data structure being those stored therein. Substructures (DF_PT, DF_AD, VAS-applications) on which the data (VAS-data) required to enable execution of transactions between the cardholder and the service provider can be loaded; A definition dataset containing information relating to the nature and / or structure of the data stored in the substructure (VAS-application), the definition dataset comprising: A denotation (container-ID) identifying a data structure (VAS-container) and / or chip card; And A chip card further comprising at least one system key (K _SO ) to secure the integrity of the definition dataset and / or data structure (VAS-container) against variations. The method according to claim 1 or 2, A transfer storage area (EF_TRANSFER) which is exchanged or submitted in the execution of a transaction and which contains data representing monetary units or non-monetary qualifications; and And a means for writing data to transfer storage in response to a write command (TRANSFER). The method according to any one of claims 1 to 3, Means for pushing data into a substructure into the substructure with the aid of at least one system key; Means for writing data into the definition dataset to adapt data of the definition dataset to data loaded into the substructure; Means for generating additional substructures through which data required to execute a transaction can be loaded into a database of cards; And / or And at least one of means for dynamic memory management for the card. The method according to any of the preceding claims, Substructures (VAS-applications) are represented by mutually independent substructures, each of which is assigned to a specific service provider, The definition dataset is protected against modification by at least one system key (K _SO ) and can only be modified by this key, The chip card, characterized in that the loading of substructures (VAS-applications) can only proceed with the use of the system key contained in the definition dataset. The method according to any of the preceding claims, wherein the definition data set is At least one authentication key (K _AUT ) for authenticating the qualification of the chip card with respect to the terminal and / or for authenticating the qualification of the terminal with respect to the chip card; At least one signing key (K _{SIG_VASC} ) for signing data removed from the transport store; A key generation key (KGK _DEC ) for generating keys specific to the terminal and application for authorization and / or verification of invalidation of the value data for the write procedure into the transfer storage; At least one of the features of a PIN for verifying authorization of a transaction procedure by a cardholder, The system key (K _SO ), authentication key (K _AUT ), signature key (K _{SGN_VASC} ) and key generation key (KGK _DEC ) are keys that are unique to the cards or special to the data structure (DF_VAS), Substructure (VAS-application), At least one value store (EF_VALUE) for storing value data; At least one internal storage (EF_INTERNAL) for storing internal data related to the substructure; At least one information store (EF_INFO) for receiving non-internal data related to the substructure; And For accommodating at least one key (K _LVASP , K _RVASP ) that provides security for writing to and / or retrieval of value stores and / or internal and / or information stores. At least one of the features of a keystore (EF_KEY), The chip card further comprises means for writing and / or retrieving to or from a value store, an internal store or an information store, The means for raising comprises a means for writing a key into a keystore protected by at least one system key. The structure of claim 1, wherein the substructure is Key to check the permission to write data to a _substructure (K _LVASP) ; And And at least one of an integer called a key (K _RVASP ) for checking permission to retrieve data from a _substructure . The method according to any of the preceding claims, wherein the keys stored in the keystore are specific to individual substructures, At least one substructure (VAS-application) allows execution of transactions for a particular substructure (VAS-application) and for other substructures (VAS-applications) among the special keys (K _LVASP , K _RVASP) . And protected by at least one independent of the keys. The card according to any of the preceding claims, wherein the card comprises a plurality of substructures (VAS-applications), each of which serves for the execution of transactions between a particular service provider and a cardholder. , Execution of transactions is characterized in that writing and / or retrieval of data from and to the transfer field, and / or writing and / or retrieval of data to and from it, individually, into a value store. Chip card according to any of the preceding claims, further comprising means for executing transactions both between the substructure and the service provider as well as between the individual substructures (VAS-applications). . The method according to any one of the preceding claims, The system key (K _SO ) is known only to the system operator (SO), is a key unique to the card and / or special to a data structure (VAS-container), The chip card, characterized in that the additional keys contained in the data set are keys specific to the card and / or special keys in the data structure (VAS-container). The method according to any of the preceding claims, wherein the definition dataset is The directory of substructures contained in the data structure (EF_DIR) contains the partial structure specific identification numbers in the substructure of the substructures (VAS-applications) loaded into the data structure (VAS-container). In addition, the information is an identification number (EF_ID) that specifies the data structure that contains that part of the data structure (VAS-container) in which the substructures (VAS-applications) are physically stored. ; And A chip card comprising one or more of the complete number, EF_VERSION, of the data structure. The method according to any one of the preceding claims, Means for executing a withdrawal procedure by removing and / or value-canceling data from the transfer store; And Means for generating one or more authenticity features of the data during recovery or cancellation of the data from the transfer storage device. The chip card of claim 1, wherein the chip card for generating certainty features comprises: A signature key K _{SIG_VASC} for generating a digital signature with recovered data; And And a means for generating a transaction number that characterizes a transaction that is also used for generation of a digital signature. The method according to any one of the preceding claims, wherein the signature key K _{SIG_VASC} is a private key derived from a private key generating key and is public key when checking the signature by the service provider. Chip card characterized in that (public key) is used. The method according to any of the preceding claims, wherein the chip card is at least: Means for generating keys K _DEC specific to the terminal and substructure by means of a key generation key KGK _DEC ; And Key (K _DEC ) specific to the terminal and substructure, At least one authentication key (K _AUT ), At least one system key (K _SO ), Special keys for at least one _substructure (K _LVASP , K _RVASP ), Signing key (K _{SIG_VASC} ), PIN, Identification of substructures, and Means for verifying the authorization and / or protection of a transaction using at least one of the entities called identification of the terminal, the chip card comprising one of the entities called. The method according to any of the preceding claims, wherein the chip card is Means for authenticating the authority and / or the terminal by an authentication key prior to a data retrieval or writing procedure, A chip card, characterized in that it comprises at least one of the following: means for executing data retrieval or writing procedures protected by digital signatures and / or key formation. The method according to any of the preceding claims, wherein the chip card is Means for making PIN-protection active and inactive, And at least one of a complete set of means for changing the PIN. The data structure according to any one of the preceding claims, wherein the data structure according to any one of the preceding claims is independent of the card platform, and the chip card, And a means for transferring the data structure or parts of the data structure to another card. A storage area for the writing or retrieval of data into or out of the storage area for the transfer of value data indicative of unit currency and / or other non-call qualifications between the same or different service providers. Chip card. A terminal for use of a chip card according to any one of claims 1 to 20, wherein the terminal comprises: Means for identifying a data structure (VAS-container) of the chip card, as well as for identifying a characterization (container-ID) for identifying the data structure, Means for retrieving data from at least one of the substructures and / or definition datasets and / or transfer storage of the card; Means for writing data into the transfer storage of the card; And at least one of the features of means for pushing data required for the execution of transactions into at least one of substructures (VAS-applications) of the card. The method of claim 21, wherein the terminal, The execution of the transaction, Writing data into the value store, Writing data into the transfer storage, Removing and / or erasing data from the transfer storage, Retrieval of data from substructures, Retrieve data from transfer storage And at least one of a complete set of means for executing transactions between the service provider and the cardholder, comprising at least one of the following steps. The method of claim 21 or 22, wherein the terminal, Key (K _DEC ) specific to the terminal and substructure, At least one authentication key (K _AUT ) unique to the card or specific to the data structure (DF_VAS), At least one system key K _SO unique to the card or specific to the data structure DF_VAS, Special keys for at least one _substructure (K _LVASP , K _RVASP ), At least one signature key (K _{SIG_VASC} ) unique to the card or specific to the data structure ( _{DF_VAS} ), PIN unique to the card or special to the data structure (DF_VAS), An application-specific characterization of a partial structure, Means for verifying the authorization for the transaction and / or the protection thereof, with the aid of at least one of a complete set of a terminal-specific characterization of a terminal. Terminal. 24. The apparatus of any of claims 21 to 23, wherein the means for writing data into the transfer storage unit is: And means for encoding data by use of a key K _DEC specific to the terminal and substructure for verification of the write permission. 25. A terminal as claimed in any of claims 21 to 24, further comprising means for executing the process of recovering data from the transport store by removing and / or devalued data from the transport store. . The method according to any one of claims 21 to 25, Means for characterizing the data of the transmission store as being removed; Means for characterizing the data on the transmission store as expired Terminal further comprises at least one of the complete. 27. The method of any of claims 21 to 26, wherein the means for executing transactions is: Means for changing value data in substructures, And at least one of a complete set of means for executing transactions between different service providers at the cardholder's expense, individually for their benefit. The terminal of claim 21, wherein the terminal comprises: Means for authenticating the card with respect to the terminal and / or the terminal with the aid of at least one authentication key; Means for protecting a transaction by the cardholder with a PIN; And means for making PIN-protection active and inactive. 29. The terminal as claimed in any one of claims 21 to 28, wherein the terminal is Means for sending a special feature description to the card to the terminal; Means for transmitting to the card a feature description specifying the substructure; Means for authenticating authorization using keys specific to the terminal and substructure as well as depicting features specific to the terminal and substructure, And at least one of the following: means for executing data retrieval or writing procedures protected by digital signatures and / or encoding. The terminal of claim 21, wherein the terminal comprises: Means for selecting a substructure (VAS-application); Means for showing the substructure to the terminal; Means for displaying the substructure data to the terminal; Means for placing the substructure (VAS-application) on a card; Means for placing feature descriptions on a carded substructure (VAS-application); Means for deleting a substructure from the card; Means for replacing a substructure by another substructure; Means for transferring the substructure to another card; Further comprising at least one of the integrals as a means for interpreting the substructure as to its function and its associated service provider, as well as for the data retrieval and viewing of the information stored therein. Terminal. A method for executing transactions between a cardholder and a terminal as well as at least one service provider involved in the use of a chip card, The cardholder and service provider as well as provision data structures stored on the chip card so that data can be loaded into it to enable the execution of transactions between the cardholder and the service provider. Writing or reading data into or from a data structure (VAS-application) to execute transactions between; During the execution of a transaction, the transfer storage area (EF_TRANSFER) is prepared for the storage of non-currency qualifications that are to be exchanged or recurred or submitted to the unit currency, as well as the writing of data into the transfer store or the transfer of data from the transfer store. A method comprising one step of a search step. 32. The method of claim 31, wherein Using a chip card according to any one of claims 1 to 20; Using a terminal according to any one of claims 21 to 30; And at least one of the steps of writing or retrieving data into or from the value store or internal store or information store of at least one of the substructures (VAS-applications). The method of claim 31 or 32, Authenticating the qualification of the terminal and / or chip card with the use of at least one key; And at least one of the steps of protecting the transaction by use of digital signatures and / or encoding by use of at least one key. In the method of uploading data to the chip card using the terminal, this method, Uploading data into the card substructure (VAS-application); And at least one of the steps of writing data into the definition dataset of the card. The method of claim 34, Using a chip card according to any one of claims 1 to 20; 31. A method according to any one of claims 21 to 30, comprising at least one of the steps of using the terminal. A system for executing a transaction, characterized by a chip card according to any one of claims 1 to 20 and a terminal according to any one of claims 21 to 30.