WO1998028718A2 - Chipkarte und verfahren zur verwendung der chipkarte - Google Patents

Chipkarte und verfahren zur verwendung der chipkarte Download PDF

Info

Publication number
WO1998028718A2
WO1998028718A2 PCT/DE1997/003012 DE9703012W WO9828718A2 WO 1998028718 A2 WO1998028718 A2 WO 1998028718A2 DE 9703012 W DE9703012 W DE 9703012W WO 9828718 A2 WO9828718 A2 WO 9828718A2
Authority
WO
WIPO (PCT)
Prior art keywords
vas
data
card
key
terminal
Prior art date
Application number
PCT/DE1997/003012
Other languages
English (en)
French (fr)
Other versions
WO1998028718A3 (de
Inventor
Holger Engelhardt
Michael Hinz
Stefan Kissinger
Michael Gollner
Anton J. Kuchelmeister
Andreas Schwier
Adelheid Burger
Michael Radnoti
Original Assignee
Deutsche Bank Ag
Bb-Data Gesellschaft Für Informations- Und Kommunikationssysteme Mbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE19718115A external-priority patent/DE19718115A1/de
Priority to JP10528242A priority Critical patent/JP2000508101A/ja
Priority to SK860-99A priority patent/SK86099A3/sk
Priority to NZ336403A priority patent/NZ336403A/en
Priority to APAP/P/1999/001573A priority patent/AP1062A/en
Priority to EP97953671A priority patent/EP0968485A2/de
Priority to PL97334183A priority patent/PL334183A1/xx
Priority to HU0000448A priority patent/HUP0000448A3/hu
Application filed by Deutsche Bank Ag, Bb-Data Gesellschaft Für Informations- Und Kommunikationssysteme Mbh filed Critical Deutsche Bank Ag
Priority to AU57487/98A priority patent/AU738719B2/en
Priority to BR9714071-6A priority patent/BR9714071A/pt
Priority to IL13017497A priority patent/IL130174A0/xx
Priority to CA002275931A priority patent/CA2275931A1/en
Priority to EA199900538A priority patent/EA001837B1/ru
Publication of WO1998028718A2 publication Critical patent/WO1998028718A2/de
Publication of WO1998028718A3 publication Critical patent/WO1998028718A3/de
Priority to IS5060A priority patent/IS5060A/is
Priority to BG103490A priority patent/BG63233B1/bg
Priority to NO993102A priority patent/NO993102L/no

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K17/00—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
    • G06K19/07716—Constructional details, e.g. mounting of circuits in the carrier the record carrier comprising means for customization, e.g. being arranged for personalization in batch
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems

Definitions

  • Chip card and method for using the chip card are Chip card and method for using the chip card
  • the invention relates to a chip card, a terminal for use with a chip card, a method for using the chip card and a chip card system.
  • microprocessor chip cards with a payment function e.g. electronic wallets, ec-cash, credit function etc.
  • a payment function e.g. electronic wallets, ec-cash, credit function etc.
  • ZKA Central Credit Committee
  • VISA Very Well Scientific Instruments
  • EMV Europay Mastercard VISA
  • chip cards can usually only be used for a specific application, for example as an electronic wallet or as an electronic ID.
  • applications applied to these chip cards are regularly static, ie they are applied during the production of the chip card and remain unchanged over the life cycle of the card.
  • Another object of the invention is to provide a chip card in which the number and type of applications or applications and transactions that can be carried out with the chip card is still variable even after the manufacturing process. It should be possible to "load" additional applications onto this chip card, it should be possible to delete applications from the chip card and the individual applications should be defined independently of one another in terms of data and security technology and run independently of one another.
  • the chip card should, for example, meet the data and security requirements according to ISO 7816; however, the individual applications of the card should in particular be independent of the card platform itself.
  • intraservices ie closed applications in the sense that there is no billing and power transmission with external partners
  • interservices ie applications with additional external relationships with external partners
  • a device is provided with which one or more card applications can be loaded onto the card, each of which enables transactions to be carried out between the cardholder and one or more service providers.
  • the chip card By loading the chip card is configured so that it receives a new functionality, i.e. can run an application that was previously not possible. Applications are defined by the loaded data and implemented in connection with the basic functionalities of the card, such as the operating system, which were not previously available on the card. The functionality of the card is expanded by loading an application with this application.
  • a data structure (DF_VAS) is provided on the chip card according to the invention, which itself is in turn subdivided into a substructure and a definition data record, the data structure being uniquely identified by means of an identifier which identifies it and is therefore independent of the card platform itself.
  • So-called applications can now be loaded into the substructure, ie functionalities or applications of the chip card. By loading a specific application of the chip card, it is thus possible to carry out transactions between the card holder and a service provider specific for this application.
  • a definition data record within the data structure contains information about the type and / or the structure of the applications loaded in the substructure.
  • a system key other security mechanisms or security devices are also conceivable, by means of which security against modifications can be made, for example by means of a personal identification number (PIN) or other security devices.
  • PIN personal identification number
  • transactions can then be carried out between the card holder and service providers, which are dependent on the loaded applications, by means of the card.
  • the chip card preferably also has a transfer memory area into which the data to be exchanged when transactions are carried out are written or from which they are read.
  • a transfer memory area into which the data to be exchanged when transactions are carried out are written or from which they are read.
  • the individual substructures or applications present in the card are preferably independent of one another and each assigned to a specific service provider. They represent, so to speak, the data proprietary or specific to this service provider for executing a specific application. They therefore contain, depending on the application type and the service - ⁇ * -
  • Mutual authentication between the chip card and a terminal preferably takes place before a transaction is carried out, an application-specific or substructure-specific authentication key being provided.
  • data is then written into a substructure reserved for the respective VAS application or read from it or processed via the transfer memory area.
  • application-specific keys are used.
  • an application-specific and preferably also a terminal-specific key is used, which is used, for example, by means of a key generation key which is provided on the card and is generated from application-specific data.
  • the data thus written into the transfer memory can then be removed by the service provider via the terminal, which is preferably done by marking the data stored in the transfer memory as canceled. If this is a service provider that is not specific for the writing application, a so-called interservice is carried out, ie monetary data is exchanged between different service providers for the benefit or at the expense of the cardholder.
  • a PIN or password for verifying the authorization of a transaction is also provided as additional security.
  • the authenticity of data taken from the transfer memory is preferably secured using a signing key or using a digital signature or at least one key. It is particularly advantageous if the extracted data remains in the transfer memory, but is only marked as removed by the card. As a result, information about the transaction carried out can still be obtained even after the transaction. With this and with the safeguarding of the withdrawal, uniqueness can also be demonstrated.
  • the transaction data or the value data can be uniquely determined and identified with regard to their associated transaction.
  • the chip card according to the invention thus consists of a hierarchical memory concept which is secured against modifications at its different levels by means of various keys and which is variable at the level of the applications with regard to the applications loaded into the memory, each individual application having its own specific one Key is secured and independent of others, and the overall structure being secured by means of at least one system key and by means of an identifier identifying the structure and being independent of the card platform itself.
  • the concept of the transfer memory enables data to be exchanged between the cardholder and service provider as well as between different service providers themselves. Reading and writing to and from the transfer memory is also secured by keys, which are also card- and application-specific, in addition, however, are also terminal-specific. Authentication, which is carried out before each transaction, and optionally a PIN or a password additionally increase the security of the chip card according to the invention.
  • Claims 21 to 30 define a terminal for use with the chip card according to the invention. This terminal is used to load or delete applications, to carry out transactions, to view data and to carry out other functions related to the respective applications and transactions.
  • a method for carrying out transactions between cardholder and service provider is defined in claims 31 to 33, loading data onto a chip card according to the invention defines claims 34 and 35, and claim 36 defines an overall system consisting of chip card and terminal.
  • FIG. 5 shows a schematic illustration of the security architecture of the chip card according to the invention
  • FIG. 6 shows the file structure of a general implementation class of the VAS container
  • FIG 8 shows the file structure of the VAS container according to an embodiment of the present invention.
  • VAS card is a chip card that can be used to participate in the value added services.
  • the VAS card contains, among other applications, e.g. Payment applications (i.e. electronic wallet) the VAS container.
  • VAS container contains data structures, access conditions, keys and (additional) commands for managing VAS applications and providing the functionality of the VAS applications.
  • VAS application VAS applications contain VAS data. Access to the VAS data is controlled by the VAS application.
  • a VAS provider operates one or more VAS applications in the VAS container. The use of the VAS application is defined by the application, reading and processing of VAS data.
  • a VAS application can be either an intra-or inter-service.
  • VAS provider The VAS provider is responsible for his VAS application, which he develops according to the framework conditions of the system operator and according to his own ideas and then makes available to the cardholders for use via the system operator and the terminals.
  • the VAS applications must be loaded into the VAS container on the VAS card before you can participate.
  • Intraservice is a type of VAS application that is used under the exclusive direction of the respective VAS provider. Intraservice applications are closed applications in the sense that there is no billing or service transfer with external partners.
  • a VAS application can be either an intra-or inter-service.
  • Interservice applications are intra-service applications that maintain additional external relationships with external partners.
  • a VAS application can be either an intra-or inter-service.
  • system operator The system operator offers the VAS providers and cardholders the VAS system for use.
  • Issuer The issuer, or card issuer, circulates the VAS cards with the VAS container.
  • CH Cardholder: The cardholder, or cardholder, is the person who owns the card (here: VAS card) and uses it to participate in the value added services _ ⁇ o - to participate. This person is not necessarily the real owner of the card
  • the service terminal is set up by the system operator for VAS applications.
  • the cardholder can manage the VAS applications on his VAS card (loading, viewing, deleting and transferring VAS applications).
  • the merchant terminal has payment functions and also offers VAS functionality. The cardholder uses his VAS card on him to pay on the one hand and to benefit from the advantages of VAS at the same time.
  • AID Application Identifier name of applications up to 16 bytes long to clearly differentiate between applications and application selection from outside without knowing the file structure of a card.
  • the AID consists of a 5 byte long Registered Application Provider ID (RID) and optionally a maximum 11 byte long Proprietary Application Identifier Registration (PIX).
  • RID Registered Application Provider ID
  • PIX Proprietary Application Identifier Registration
  • Valid VAS container VAS container that can authenticate itself to the outside world.
  • KID (Key Identifier) Number of a key within an elementary file that contains keys
  • nr DIR Maximum total number of objects: nr D
  • R p + a The number of records in EF_DIR is nr D
  • Fig. 1 shows schematically the structure of the chip card according to the invention.
  • a directory or a data structure or file structure DF_VAS is also provided on the card according to the invention. This serves to include additional functionalities, so-called Value Added Services VAS. Because of these additional functionalities, which represent applications that can also be loaded onto the card at a later point in time, i.e. after the card has been produced, the card is flexible and variable with regard to its functionalities and the transactions that can be carried out with it.
  • VAS container provided on the chip card according to the invention enables the variability and flexibility of the chip card with regard to its functions and also detaches the applications accommodated on the chip card from the card platform in terms of security, so that they are independent of the card platform and possibly even on one other card can be transferred.
  • the new additional functionalities (Value Added Services, VAS) according to the invention are implemented by microprocessor chip cards.
  • the implementation of these additional functionalities is realized by the VAS container.
  • the VAS container on the microprocessor chip card forms the platform for receiving the VAS applications.
  • the VAS applications are the respective implementations of certain additional functionalities.
  • payment with the card (payment function)
  • the use of a VAS application (additional functionality) are handled via separate mechanisms; from the point of view of the card user or card holder, however, this can appear as one process.
  • the microprocessor chip card is expanded to include the VAS container, which can hold various and independent applications. It provides functions for applying, deleting and transferring these applications; these can only be used by the authorized system operator.
  • the VAS container is independent of other system components on the microprocessor chip.
  • the VAS container is completely self-defined and works on its own.
  • An independent security architecture is defined for it, so that VAS applications use independent security functions.
  • the security architecture uses card-specific keys that are not manufacturer-specific and that are independent of identification features of the card platform.
  • the VAS container also uses mechanisms to derive terminal-specific keys. With these, the VAS container itself can actively check the authenticity of terminals or the data they generate.
  • the VAS applications are stored in the VAS container, which provide data via mechanisms of the VAS container and thereby control the assigned interfaces.
  • the VAS container also enables and controls the secure exchange of data for inter-services between partners.
  • the VAS container actively checks, i.e. the authenticity and uniqueness of the transferred data values.
  • Card platform is. It offers a security architecture that is independent of platform-specific security mechanisms (such as keys,
  • VAS container concept Another advantage of the VAS container concept is that the number of different applications on the card is not predetermined by restrictions and requirements at the time of card production or card issuance; The current card assignment with applications can be freely selected by the card user and is only limited by the storage space available on the respective card.
  • the number of VAS applications currently loaded on a card depends on the actual use of the card.
  • the card user individually compiles the VAS applications on his card; this also includes changing the compilation at a later date.
  • the VAS container enables a multifunctional card, in which the card functionality can be combined and used in the number and type of applications during the life cycle of the card. This means that applications that previously required individual, special cards can also be stored on one card and used. VAS applications can also be transferred to other cards. This enables VAS applications to survive the life cycle of a card; they accompany the card user throughout the life cycle of the applications.
  • the microprocessor chip card with additional services is a suitable medium for the dissemination and marketing of services in which protected data must be accessed.
  • This microprocessor chip card can be used as a means of payment, computing unit and for storing value. It can be flexibly provided with additional services by the customer himself and after card issuance and used to control them. It also actively controls the authenticity of the terminals involved and ensures the uniqueness and authenticity of the data transferred.
  • VAS applications can be loaded, deleted and transferred at service terminals (ST); further operations are: select, view, interpret VAS application, etc.
  • VAS providers design their own VAS applications according to the framework conditions of the system operator and, if possible, according to their own ideas.
  • VAS providers design their own VAS applications according to the framework conditions of the system operator and, if possible, according to their own ideas.
  • the corresponding terminal programs can be checked for authenticity.
  • Fig. 3 shows the data flow in the system.
  • VAS applications are made available to the card users by the system operator at the terminals. VAS applications must be loaded into the VAS container of the chip card according to the invention before it can be used.
  • VAS applications on the card are used at dealer terminals (HT) by applying or deleting VAS data.
  • the VAS container is attached to the card in addition to other existing applications (e.g. payment applications such as the electronic wallet).
  • the VAS container uses functions that enable the application, deletion and transfer of VAS applications. These management functions are used exclusively by the system operator and are secured on the card against unauthorized use.
  • the VAS container contains a transfer memory with which the exchange of data between VAS applications is realized. Two commands TRANSFER and TAKE are used to control the transfer memory.
  • the TRANSFER command creates an entry in the transfer memory with data specific to the respective application. In addition to the user data, this also includes the information required to control processing, such as the date, expiry date and identification data.
  • TAKE command objects are removed from the transfer memory and marked as removed. Depending on the application, the objects are then marked as still valid or as invalid. Transmitted data is checked for authenticity and uniqueness by the VAS container.
  • VAS applications use VAS data to provide and control the applications. Access to the VAS data is controlled by the VAS application, which uses mechanisms that are provided in the VAS container for all applications.
  • a VAS provider operates one or more VAS applications in the VAS container. The use of the VAS application is defined by the application, reading and processing of VAS data.
  • the VAS container supports interservices. Interservices require access to common data, transfer of service claims and the billing of services between different partners.
  • the description relates to the appearance and function according to the prior art.
  • the function should be simulated in the future by one or more VAS applications.
  • Example A Customer club A department store operates a customer club. The customer becomes a member of this club and with this status receives specific club services that non-members cannot receive.
  • a club member identifies himself in the club environment with a club ID. The club ID is issued upon entry, is non-transferable and is usually valid for a period of time. No specific transactions are processed via the club ID, ie there is no link to customer turnover. This distinguishes the club ID from bonus programs in which there is a relationship between status and sales.
  • Goal The club membership should be verified by an application in the VAS container.
  • a customer receives a bonus claim for every transaction.
  • the bonus claim is accumulated and can be exchanged for a monetary benefit at a time defined by the customer.
  • the bonus claim is valid for a defined period of time and can be managed anonymously or personally.
  • the bonus claim arises from sales or frequency of use.
  • Goal The points account should be managed by an application in the VAS container.
  • the customer receives a volume discount according to the plan.
  • the discount is granted for each individual transaction.
  • the card does not maintain a sales history. Every transaction is self-contained.
  • a person can use features on the card to prove to third parties that there is entitlement to certain services.
  • the identity of the person to the ID must be proven with every transaction (photo, PIN, biometrics).
  • the authenticity of the ID card is used as a security feature.
  • Goal The authorization should be verified by a VAS application.
  • Units of value are acquired and used through one or more uses.
  • the value is reduced by one or more units per transaction.
  • the usage authorization is transferable and may include restrictions on use.
  • Example F Usage billing - ⁇ 8 -
  • the use of a service is registered according to time, frequency or quantity and billed according to the tariff plan. It is not known in advance to what extent the
  • a VAS application should enable billing according to tariff.
  • the currently required accounting data should be stored in the VAS container.
  • Example G Notepad (mobile data storage)
  • This application enables the cardholder's data to be transferred to the VAS provider. This automates processes that are currently still done manually. No monetary equivalent can be derived from this data.
  • a VAS provider should take the data from the card and thus be able to provide the corresponding service directly (e.g. establish a telephone connection, compile the desired goods, electronically fill in and enter the lottery ticket).
  • the data can be saved on the map both in the short and long term.
  • a department store reimburses a customer the ticket of a public transport company for the journey to the department store.
  • the customer must present the single ticket to the department store.
  • the department store notes on the ticket that it has been refunded.
  • the department store may receive part of the reimbursement to the customer from the transport company.
  • a department store reimburses the customer for the cost of a trip home by purchasing a voucher.
  • the customer receives a public transport ticket at a ticket counter or pays a lower price for the ticket.
  • the transport company settles the voucher with the department store.
  • Goal Mapping of the mechanisms through VAS applications with electronic billing between retail and public transport.
  • a department store reimburses part of the parking fee to the customer when using a specific parking garage.
  • the car park is operated by an independent company and receives monetary compensation from the department store for each customer credit.
  • Goal Mapping of the mechanisms through VAS applications with electronic billing between retail and parking garage.
  • Example D Multilateral bonus program - Z O- A group of retail companies and service providers agree on a joint bonus program.
  • Each partner can have bonus points in a joint account on the
  • Each service provider operates its own bonus program, but has to recognize agreements with other, collected points.
  • Known examples are agreements between car rental companies and airlines to collect "miles”.
  • Every VAS provider should first collect its points for itself without anyone else being able to intervene. Secure mechanisms should be provided for the transmission.
  • a public transport ticket also entitles you to travel in a shared taxi (e.g. after 10 p.m.).
  • the taxi company must provide proof that the ticket has been presented.
  • the use of the taxi is noted on the card to prevent misuse.
  • the structure of the chip card according to the invention will be described in more detail below. -2 ⁇ ⁇
  • the microprocessor chip card with VAS functionality contains in particular the VAS container.
  • the VAS container is an independent application and exists either alone or in parallel with other applications on the underlying card platform.
  • the VAS container is completely self-defined and works on its own. It can be operated without the payment function usually available on the same card.
  • an independent security architecture is defined for the VAS container, so that VAS applications can use independent security functions.
  • Part of the value added services are transactions by the customer, which are carried out at terminals of the VAS providers.
  • the VAS provider has an interest in tracking these transactions, be it for system monitoring purposes or to collect statistical and other data.
  • To optimize and standardize the data structures in the card the use of application-specific identifications is discouraged and the use of a system-wide unique VAS container ID is recommended. This number can be used by the VAS provider to implement the above. Functions are used, and it frees him from the burden of managing his own number ranges.
  • the security architecture of the VAS container uses this system-wide unique ID to derive card-specific keys.
  • the use of the card-specific number would be possible in principle, but is preferably not used, since if the VAS container is implemented on different platforms, these may use conflicting number ranges.
  • the VAS container ID is assigned by the system operator and inserted by the card operator when the VAS container is created. It is destroyed when the VAS container is deleted and thus removed from the system.
  • VAS container is considered deleted if it does not contain any VAS applications and the
  • VAS container ID is removed.
  • the VAS container ID is transferred together with the VAS applications. This transfer corresponds to moving the VAS container from the old to the new card. After this process, the old card no longer contains a VAS container. The VAS container in the new card is overwritten during this operation and thus deleted. Since the VAS container ID is transferred from the old card to the new one, no conversion of the reference number is required in the background systems of the VAS provider.
  • VAS applications can only be moved between two different VAS containers under the control of the respective VAS provider. With this function, the assignment between the VAS container ID and the VAS application changes, which may must be noted in the background system of the VAS provider.
  • VAS container does not contain any personal characteristics.
  • VAS applications can contain personal data, but the scope should be kept to a minimum for data protection reasons and for better memory utilization. If necessary, VAS applications should store personal data in the background system and establish the assignment to the card using the VAS container ID.
  • a key feature of the VAS container is the support of interservices. Interservices require access to common data, transfer of service claims and the billing of services between different partners.
  • the VAS container must enable this and still guarantee the security of the applications in the intraservice.
  • So-called Intraservice VAS applications are applications that are operated under the exclusive control of the VAS provider.
  • the VAS provider defines the security of its application independently of an external body. No external party can change VAS data without passing on the key.
  • the partners In order to process interservices efficiently, the partners must have access to shared data.
  • the shared access to the data is implemented via graduated security mechanisms.
  • the first level of shared access takes place exclusively via public transfer fields.
  • VAS providers can use these fields to exchange data without having to know each other's applications and keys.
  • the terminals only need suitable keys to write data to the transfer fields, but not to read them.
  • People can read without restriction.
  • Data can be exchanged in both directions between the VAS provider and partner if everyone has their key for writing.
  • the transfer data can be generated from an Intraservice VAS application by the VAS provider or, conversely, the VAS provider can take data from the transfer field into its Intraservice VAS application.
  • the second stage is the devaluation of value units that are embodied by VAS data.
  • a VAS provider introduces units of value into the VAS data with a special key for writing.
  • the value units can be worn by Interservice partners who have a key for validation, which they get from the overall responsible VAS provider.
  • partners with different rights access non-public VAS data.
  • the third stage is direct write access to the VAS data by all participating Interservice partners. This method requires a corresponding level of trust between the parties, since VAS data can be changed without restriction. - 2M -
  • the transfer field serves as a coupling link between VAS applications. Dates in
  • Transfer fields are generated by the VAS applications in the VAS container. Data can also be created directly in the transfer field if the producer does not operate his own VAS application in the VAS container.
  • the transfer field is in principle available to all applications, but only those who have the authorization (key) are allowed to write. Only according to the rules, i.e. the rules and regulations R&R, authorized recipients may take data from the transfer field. The recipient checks the existence of transfer data intended for him and removes it for processing in his own system.
  • the producer introduces an authenticity feature and the VAS container a sequence number. These elements ensure the uniqueness of a transfer message and the origin of the data is verified.
  • the recipient of the transfer data is equipped by the producer with the option of carrying out an authenticity check. If this is not desired, the data can also be accepted in good faith; the authenticity feature may then be only checked during billing in the background system of the generating VAS provider.
  • the data can only be removed from the transfer field once with receipt of an authenticity feature. When the data is removed, it is marked and remains (as a copy) in the transfer field. This means that the transfer process can also be verified for a certain period after the data has been extracted.
  • Transfer fields can be marked when they are removed so that they are released for immediate overwriting. Should the transfer memory fill up completely before a transfer data record expires, the cardholder must delete entries that are no longer required at the service terminal.
  • the process generates an electronic receipt that is placed in the transfer field.
  • This receipt has a useful expiry date on which it can be deleted from the transfer memory.
  • Removal Generally the removal of the electronic receipt from a transfer field for further processing (e.g. background system). A copy of the receipt remains and serves as proof of "validation".
  • VAS applications with common features can be divided into classes. These classes form the basis for data structures in the VAS container.
  • the VAS provider selects an application class when implementing its application.
  • Point storage refers to an application class in which an account is managed by point values. Values can be booked and deducted from the points account. The VAS provider posts values by writing to the memory with the new account balance. Values are debited using the "validate" operation, with an electronic receipt being stored in the transfer memory as evidence. Access to the two functions is realized using two different access keys.
  • Ticket denotes an application class in which a value field exists that is canceled once or several times and is therefore used up. Values are booked once in the ticket application class.
  • ID card denotes an application class in which the VAS data include proof of authorization. Evidence is usually not provided by
  • ID e.g. resident parking ticket
  • ID document e.g. shared taxi ride with monthly ticket: generation of an electronic receipt using the card.
  • the receipt is submitted by the taxi company to the public transport and charged proportionally).
  • use of the ID can be documented by electronic receipts in the card's transfer memory.
  • Voucher refers to an application class in which performance claims (usually at short notice) are temporarily stored in the card. These electronic vouchers are only stored in the VAS container's transfer memory. The application that uses the voucher is usually a different application than the one that generated it. The voucher can only be removed from the transfer store once and is documented by the card. An authenticity feature generated by the VAS container can be used for billing in the background system.
  • Data storage refers to an application class in which a VAS provider stores data in the VAS container that offers the customer an additional service (e.g. last menu in fast food restaurant, last lottery numbers, service preferences, suggestion lists).
  • the data is for information only and does not constitute a claim against the VAS provider. Access to the data is controlled by the VAS provider.
  • Each application class is characterized by a typical usage cycle.
  • the following table shows the frequency at which the three operations defined above are applied to the VAS data of the application class (note: “Acquire” does not mean “Load application” and “Remove” does not mean “Delete application”). - 2 ⁇ -
  • the security architecture is based on the lifecycle of VAS containers or VAS applications and is stratified according to the responsibility of the entities involved. An explanatory schematic representation is shown in FIG. 5.
  • VAS container and VAS-specific supplementary commands are either put on the card by the issuer together with other non-VAS applications or integrated at the latest at a service terminal by an authorized VAS provider on an existing card platform.
  • the system operator arranges a temporary key K so * with the issuer.
  • the issuer opens the card with his only known key, creates the files of the VAS container and in particular writes the K so * in the DF_VAS.
  • the system operator can then replace the key K so * with his own key K so at a later time (for example, the card comes into contact with a service terminal for the first time), which then only he knows.
  • the system operator can now enter additional data such as the KGK DEC himself or, in the case of a platform with dynamic memory management, create or delete files for VAS applications.
  • the issuer should act on behalf of the system Operator place the VAS container including all keys on the VAS cards.
  • the VAS container consists of a predefined file structure, predefined access conditions (ACs) and some global data.
  • the global data include the key K so for loading or deleting VAS applications. This key, which only the system operator knows, ensures that only approved VAS applications can be loaded.
  • the card requires an external authentication of the system operator with K so .
  • a cardholder wants to load a VAS application at a service terminal, the responsible VAS provider instructs the system operator to do this for him.
  • the VAS provider gives the system operator the keys K LVASP and K RVASP , which he then enters into the application.
  • K LVA SP key With the K LVA SP key, the VAS provider can protect data of the application against write access and additional internal data against read access.
  • the card requires an external authentication of the VAS provider based on K LVASP ; ie the card actively checks the authenticity of the terminal. After successful execution of this function, a terminal is granted write access to a VAS application and read access to internal VAS data of the application.
  • An internal authentication ie the authenticity of the VAS application (and thus the card) can be checked by the dealer terminal.
  • these internal VAS data can be written or changed in any application that has the K LVA SP key.
  • the "Acquire" function is therefore based on an UPDATE RECORD command, which must be preceded by an external authentication with the key K LVASP .
  • Read access to all non-internal data of the VAS application is only permitted if prior external authentication by K RVASP or by K so or by the correct entry of a PIN or a password by the System operator is done.
  • the PIN- / password-protected access is provided to make data visible to the cardholder at terminals or on the wallet.
  • the cardholder has the choice of activating or deactivating PIN / password protection for reading the value or status data for all applications at the same time.
  • belongs to the global data of the VAS container GV ASC for signing extracted data from the transfer field.
  • the integrity of this transaction data can be checked if it has to be tamper-proof between Interservice partners for mutual settlement.
  • GV ASC and a transaction counter managed by the VAS container is added for data records that the card issues with the "Remove” operation. Since the transfer field is read by everyone is permitted, but the signature of the card with K SIG VASC is only generated when the " Remove " operation is called (and this can only be done once), the impermissible double billing of vouchers is recognized.
  • Each Interservice partner can have the authenticity and uniqueness of a voucher taken confirmed by the system operator. The system operator can also verify the authenticity of the VAS container by checking the signature.
  • G VASC also uses a private (secret) key within the card for signing or such a key can be derived from a private key generating key.
  • the VAS provider could use public (non-secret) keys to check the signature without having to consult the system operator.
  • VAS provider is only the application-specific derivation of the global
  • the application-specific terminal key is then calculated as follows:
  • Each card stores a key
  • This VAS provider uses KGK DEC PIX to derive its specific keys for all terminals that are to use the TRANSFER command on VAS application A using their terminal ID:
  • the VAS provider stores these keys in its terminals. If the
  • VAS provider does not operate the terminals himself, he generates the keys and distributes them to the operators of the terminals.
  • the VAS card only carries out the TRANSFER command if the command contains a cryptogram C generated by the terminal, which is formed in the transfer memory via certain data data of the message.
  • the card itself knows KGK DEC and receives the terminal ID and the PIX from a terminal in addition to the user data data and the cryptogram C (or the card knows the PIX itself, see also the description of the TRANSFER command).
  • the card now compares the self-calculated cryptogram C with the cryptogram C calculated by the terminal. If they are different, the transaction is terminated with an error message. In the event of a match, the VAS card will execute the TRANSFER command.
  • the different security standards are different
  • a terminal must authenticate itself to the card in order to carry out the "validate” operation by knowing a key K DEC . If the key K DEC is compromised, the attacker can only perform the functions of this one terminal. However, this process is logged in the card.
  • the documentation contains a unique sequence number, the validation and the terminal ID.
  • the VAS applications use the security services of the VAS container to regulate access to VAS data. The execution of VAS-specific functions is restricted by the definition of access rights to authorized parties .
  • differentiated access protection can be realized by dividing the VAS data into four elementary files, as shown in FIG. 6.
  • the four elementary files contain the following data or are protected as follows: - 2> p
  • This structure of elementary files supports the same differentiated access rights for all application classes.
  • the application classes point storage and ticket require the same resources EF_KEY, EFJNFO, EFJNTERNAL, EF_VALUE and are therefore combined to the implementation class "DF_PT”.
  • DF_PT For the application classes ID and data storage the elementary files EF_KEY and EFJNFO are sufficient and are therefore combined to the implementation class "DF_AD”.
  • DF_PT For the application classes ID and data storage the elementary files EF_KEY and EFJNFO are sufficient and are therefore combined to the implementation class "DF_AD”.
  • the Transferfeld implementation class is used specifically for the Voucher application class, which is intended to contain public read access for all VAS participants to share data. Write access is only possible indirectly by using the TRANSFER command, which requires a signature with a correct K DEC .
  • This implementation class consists of exactly one entry in the elementary file EF_TRANSFER, which belongs to the global data of the VAS container. The objects of this class are records in this file. We also call this implementation class "EF_TRANSFER".
  • the storage model can be provided in two ways. The choice depends on the card platform: - Fixed partitioning of the storage area for the VAS container:
  • the maximum number p or a of objects is determined by the issuer and these are loaded by the issuer onto the card using CREATE FILE commands.
  • DF_PT or DF_AD the maximum number p or a of objects is determined by the issuer and these are loaded by the issuer onto the card using CREATE FILE commands.
  • DF_PT or DF_AD the objects with DF_PT or DF_AD
  • VAS applications can later be loaded into free objects that are not occupied by other VAS applications. Only UPDATE RECORD commands are then required to load or delete VAS applications.
  • the issuer thus determines the number of possible objects of the two implementation classes according to its own needs; this may not match the actual VAS usage behavior of the cardholder.
  • the division is maintained over the entire life cycle of the card.
  • a VAS application is loaded into an object that is of a suitable implementation class.
  • a VAS application that represents an ID card can also be accommodated in an object of the implementation class DF_PT if no objects of the implementation class DF_AD are available.
  • a VAS application is assigned to an object by entering a trip ice
  • This variant is used for card platforms that do not support dynamic creation or deletion of DF / EF structures.
  • the DF / EF it occupies is completely removed from the card and the storage space is released.
  • the maximum number of objects of implementation classes is not explicitly determined by the issuer and only depends on the available storage space
  • This variant requires dynamic memory management by the card operating system.
  • VAS container and the functionality of the VAS customer card can be implemented compared to other system components.
  • VAS operations are defined that describe the respective interaction between the VAS container and the terminal.
  • each card regardless of the platform, provides the same data and command interface.
  • the required commands are therefore clearly described in their coding.
  • Service terminals are able to recognize the card platform.
  • the functionality can therefore be achieved through specific commands of the platform.
  • This - ⁇ - Processes are therefore described informally in some cases. How this function is provided is up to the card manufacturer.
  • FIG. 7 schematically shows the file structure of the VAS container
  • FIG. 9 shows schematically the file structure of the implementation class DF_PT
  • FIG. 10 shows the file structure of the implementation class DF_AD.
  • Access to the files of the VAS container is explicitly restricted by the following access conditions (AC):
  • the AC have the following meaning:
  • K L VASP External authentication of the VAS provider must be carried out with the key K LVAS P before access.
  • K RVASP Before access, external authentication of a term authorized by the VAS provider must take place with the key K RVASP .
  • Data fields within the records of elementary files are differentiated according to the following formats: ASCII, binary, BCD, date, format string.
  • Data elements of the "format string” type contain VAS data in a packed format that can be displayed to the cardholder at the terminal.
  • the elementary file EF_ID of DF_VAS consists of a record that contains the VAS container ID.
  • the elementary file EF_DIR of DFJVAS consists of nr D , R records. For each VAS application loaded into the VAS container, its proprietary identifier extension (PIX) and its physical storage space (FID of DF_X, into which the application was loaded) are recorded in a record of the EFJDIR. For example, the PIX identifies the application and the service provider to which the application is assigned as a code.
  • PIX proprietary identifier extension
  • FID of DF_X physical storage space
  • EF_DIR The entries in EF_DIR are created dynamically at the system operator's service terminal. Records without an entry are created with an empty TLV object '61'.
  • the elementary file EFJVERSION of the DFJVAS consists of a record that contains a version number of the VAS container.
  • the version number can be used by terminals to differentiate between different VAS container variants and / or different software versions.
  • the DFJVAS elementary file EFJ3EQ consists of a record that contains the number of the next transfer field entry.
  • the sequence number is read by the TRANSFER supplementary command. This command then creates one in the transfer field EFJTRANSFER - 41- Record in which the sequence number from EFJ3EQ is transferred. Together with the command TAKE, which ensures that every record from the
  • Transfer field is removed only once and this removal is documented by signature using the sequence number, the one-time removal of (original) vouchers or receipts can be guaranteed.
  • the transfer memory will now be discussed in more detail below.
  • the transfer memory is created within the VAS container and comprises no EF TRANSFER records. Entries in the records of this file contain transfer data that are generated by the TRANSFER command. The data exchange between VAS applications and the storage of VAS data of the voucher class are processed via the transfer memory.
  • the transfer memory can be read without restriction, but write access is only possible using the VAS-specific commands TRANSFER and TAKE.
  • the data fields are assigned by the TRANSFER command using a "last-recently-used" algorithm in the card.
  • the oldest record in the file can be found by searching for the smallest value in the first 2 bytes of the record.
  • Data fields can be marked as removed and / or removed with the "TAKE" command in the transfer memory. In any case, data in the transfer memory is deleted by overwriting with new data.
  • Each record in the transfer memory contains, for example, an expiry date, the terminal ID, the PIX, the sequence number and possibly other data.
  • VAS Application included which can be read out for the operation VAS applications.
  • the VAS provider must provide sensitive data using suitable external data
  • This EF is readable if there is an external authentication with K so or K RVASP or if the cardholder enters a correct PIN if the PIN protection is activated.
  • PT 1 f ..., PT P , AD., AD a consists of a record, the internal VAS data of the
  • VAS provider can contain via its loaded VAS application. Neither cardholder nor any other VAS provider can read this internal data.
  • the following key fields are used by the VAS container or by the VAS application. In the following, a pure DES encryption is assumed. That all keys of the VAS container are DES keys and are encoded in 8 bytes (including parity bits).
  • KID Key Identifier
  • Every key is linked to a misuse counter. This registers failed authentication attempts with this key and blocks further use if a limit for this counter has been entered and reached.
  • Every key is linked to a misuse counter. This registers failed authentication attempts with this key and blocks further use if a limit for this counter has been entered and reached.
  • the VAS container contains a personal identification number or password (PIN). This is used by the VERIFY command to identify the cardholder.
  • PIN personal identification number or password
  • the PIN is linked to an incorrect operation counter, which registers every incorrect entry and blocks the PIN comparison when a limit is reached. This lock can be reset by the system operator using suitable administration commands.
  • the operating error counter is reset if the PIN is entered correctly. -MS " -
  • VAS container There are the following parameters for the VAS container, which can be selected by the card issuer according to the space available on a card platform and his individual wishes:
  • the minimum memory requirement for the VAS container is as follows (without memory requirement for supplementary commands):
  • the maximum memory requirement is probably about 10% higher than the minimum memory requirement.
  • the READ RECORD command is used to read data from linear elementary files.
  • the card returns the content of the record in the reply.
  • the EF is referenced by the Short File Identifier (SFI).
  • the status code '9000' signals successful execution of the command; any other code is considered an error.
  • the UPDATE RECORD command is used to insert data into the records of a linear EF.
  • the command message contains the reference to the EF, the record and the data.
  • the response from the card contains the status code.
  • the status code '9000' signals the successful completion of the commands.
  • Other status codes indicate the fault.
  • the GET CHALLENGE command requests a random number from the card.
  • the random number is used in connection with dynamic authentication in EXTERNAL AUTHENTICATE.
  • the card's reply message contains an 8-byte random number and the status code.
  • the status code '9000' indicates the successful execution of the command.
  • Other status codes indicate the fault.
  • EXTERNAL AUTHENTICATE allows a terminal to be authenticated against the card.
  • EXTERNAL AUTHENTICATE is used in the context of VAS applications to authenticate the system operator and the VAS provider.
  • EXTERNAL AUTHENTICATE transfers a cryptogram to the card, which must first be generated by the terminal by encrypting a random number. The card compares the cryptogram with a reference value that it itself calculated using the same procedure. If both values are the same, the card internally notes that the authentication access condition for this key has been fulfilled. If the comparison turns out to be negative, the card returns the status "unauthorized" and decrements an internal operator error counter. If this counter reaches the value 0, each further execution of the EXTERNAL AUTHENTICATE with the status "authentication blocked" is rejected.
  • the card reply message contains the status code.
  • the successful execution of the command and the authentication of the terminals against the card is indicated by the status code '9000'.
  • Other status codes indicate the fault.
  • the INTERNAL AUTHENTICATE command is used to check the authenticity of the VAS container using a terminal.
  • the card calculates a cryptogram using reference data from the terminal.
  • the terminal in turn forms the cryptogram and compares it with the value from the card. If they are the same, the terminal can assume the authenticity of the VAS container.
  • the response from the card contains the cryptogram and the status code for executing the command.
  • the successful execution of the command will indicated by the status code '9000'.
  • Other status codes indicate the fault.
  • the VERIFY command is used to verify the cardholder PIN.
  • the command transmits the PIN data unencrypted to the card, where a comparison with a stored reference value is carried out. If the entered and stored values are identical, the access condition "PIN" is considered fulfilled.
  • the card reply message contains the status code.
  • the status code '9000' indicates the successful execution of the command.
  • Other status codes indicate the fault.
  • the TRANSFER command creates an entry in the transfer memory.
  • Three working modes are defined for the command:
  • the working mode is automatically selected by the card: If the command is executed within a selected application DF, the presence of an EFJ / ALUE is first checked. If EFJVALUE is present, the card executes the command in mode 1, otherwise in mode 2. If no application DF is selected within the VAS container, mode 3 is used.
  • the terminal supplies the card with the following data when the TRANSFER command is called: • Current date
  • the card executes the following sequence when the TRANSFER command is called:
  • the TAKE command provides the following modes:
  • the command message contains fields with terminal ID, PIX of the application and a random number generated by the terminal.
  • the PIX in the command designates the withdrawing application. It can be different from the PIX of the data record that is extracted. It is used exclusively to derive K DEC from the withdrawing dealer terminal.
  • the reply message from the card contains a cryptogram C-, with K S
  • the reply message also contains the status code.
  • K DEC is derived as previously described. With the cryptogram by means of K DEC , authenticity is implicitly provided by the VAS container.
  • the cryptogram C is used to calculate a proof of authenticity and uniqueness (since C is formed by the sequence number, the bit taken from the transfer field record and the VAS container ID), which the system operator can verify.
  • the status code '9000' indicates the successful execution of the command. Other status codes are interpreted as errors.
  • the command message contains, for example, fields with an expiry date, the terminal ID, the transaction data, a field for the operating mode (contains the PIX in mode 3, for example) and a cryptogram.
  • the cryptogram is calculated using the key K DEC , the data over which the MAC is formed comprising, for example, the transaction data and the terminal ID.
  • the response message of the TRANSFER command includes an 8-byte data field and the 2-byte status code '9000'.
  • Reply messages with a status code other than '9000' are interpreted as an error code.
  • the data field of the response message contains the cryptogram of the command message encrypted with K DEC . This implicitly (instead of an internal authentication with K AUT ) provides proof of authenticity by the VAS container.
  • the TAKE command is used to remove objects from the implementation class EF_TRANSFER.
  • the execution of the TAKE command means reading a record to be specified from the EFJTRANSFER file, the record remaining in the file until the storage space is required for new entries, the data record is marked as removed.
  • the VAS provider who wants to take out a voucher or a receipt, searches the transfer memory for a suitable data record (eg with the SEEK command or by reading each record explicitly). The data record is read in any case and the content checked if necessary.
  • a directory containing VAS application A can be selected with SELECT FILE ⁇ PIX A >.
  • the UPDATE KEY (KID, K) is a command that is dependent on the card platform and is used to replace a key with a key identifier ID with the new value K.
  • DF_PT or DF_AD this corresponds to the application classes point storage, ticket, ID or data storage
  • DF_PT or DF_AD this corresponds to the application classes point storage, ticket, ID or data storage
  • the service terminal checks whether a VAS container is available:
  • the validity of the VAS container is checked. That requires
  • the service terminal checks the answer and terminates in the event of an error (with an error message).
  • the service terminal offers the cardholder several options to choose from. One of them is the Laden VAS application. The cardholder selects these. Now the cardholder is shown all VAS applications that can be loaded at the service terminal and a selection is waited for. To do this, the View VAS applications operation is activated. The cardholder selects a VAS application A
  • the service terminal examines the VAS container whether the selected VAS application with PIX A is already loaded on the card. If so, an error message is issued. If not, it is checked whether an object of the implementation class suitable for A is still free in the VAS container. This is done by looking for a free record in EFJDIR (eg with the SEEK command). If nothing is available, an error message is issued. If a record is free, it contains an FID DF X of a DF_X in which no VAS application is loaded.
  • the next free object of the implementation class suitable for A is occupied for VAS application A.
  • the service terminal requests two keys offline from the VAS provider (e.g. through a VAS provider SAM)
  • the operation entry VAS application ⁇ PIX A , FID DF X > is carried out by the service terminal, which connects the DF_X with the PIX A and thus SELECT FILE using the PIX A (after the previous selection with SELECT FILE AID VAS ).
  • the mechanism provided with the transfer memory can be e.g. from VAS providers who want to handle intra- or inter-services without proprietary DF structures. A cardholder then does not have to load it at a service terminal before using a VAS application. On the other hand, he can issue a voucher or receipt directly at the dealer terminal and have it reimbursed at another terminal (by removing the operation) or simply present the voucher or receipt (by reading).
  • the loading of a VAS application of the implementation class EFJTRANSFER is therefore implicitly implemented by applying VAS data or attributed to this operation. For this, reference is made to the later description of the acquisition of the implementation class EFJTRANSFER.
  • DF_X with X PT 1 f ..., PT P , AD ⁇ ..., AD a the VAS application or whether it's loaded at all. From the point of view of Card manufacturer are two possible ways of implementation, which should be checked separately; the consistency with the ZKA standard is particularly important.
  • the first case access to EFJDIR possible
  • EFJDIR e.g. under DFJVAS
  • AIDs are assigned to the FIDs of DF_X in which VAS applications are currently located.
  • the file EFJDIR can be extended by the entry PIX A , which refers to this DF_X with FID X.
  • the AC UPDATE RECORD should force an external authentication with the key K that.
  • the entry PIX A (more precisely the pair PIX A and the reference to DF_X) should be deleted from EFJDIR (eg by UPDATE RECORD with prior external authentication with the key
  • the operation entry VAS application runs as follows:
  • a VAS application A with PIX A was previously loaded into a free DF_X with FID DF X.
  • the number of the record with FID DF X was noted by the service terminal.
  • VAS applications of the implementation classes DF_PT or DF_AD can only be deleted at service terminals (under the authority of the system operator) at the request of the cardholder, VAS applications of the implementation class EFJTRANSFER can be deleted anywhere and by anyone. When deleting, a distinction must be made between VAS applications of the implementation classes DF_PT and DF_AD or the implementation class EFJTRANSFER.
  • the cardholder inserts a VAS card into a service terminal.
  • the service terminal checks whether a VAS container is available:
  • the service terminal offers the cardholder several options to choose from. One of them is Delete VAS application. The cardholder selects these. Now the cardholder is shown all VAS applications of all implementation classes that are loaded in the VAS container, and a selection is waited for. Operation VAS-
  • the cardholder selects a VAS application A of the implementation class DF_PT or DF_AD with AID A.
  • the object in which the VAS application is loaded is called DF_A.
  • a VAS application of the implementation class EFJTRANSFER should only be deleted at the request of a cardholder at a dealer terminal or service terminal (even if this would be technically possible by both). Deleting an object from EFJTRANSFER is particularly necessary if the transfer memory no longer contains space for storing a new object (e.g. a voucher or a receipt). Deletion is always done indirectly using the TAKE command. This command marks only one object as removed. It is now released for overwriting with a subsequent TRANSFER supplementary command.
  • the terminal checks whether a VAS container is available:
  • the terminal offers the cardholder several options to choose from. One of them is Delete VAS application. The cardholder selects these. At least the VAS applications of the implementation class EFJTRANSFER are now shown to the cardholder, and a selection is waited for. This is realized through a special case of the operation View VAS applications. The cardholder chooses an object
  • the terminal marks the record with record number A as removed by giving A, a random number calculated by it, its PIX and Terminal ID with the
  • VAS application A of the implementation classes DF_PT or DF_AD has been loaded into the VAS container with the Load VAS application operation, it can be selected in two stages by a terminal. First the VAS container is selected and then the VAS application with its PIX A : 1. SELECT FILE ⁇ AID VAS > (error message if VAS container cannot be selected)
  • a service terminal can check the authenticity of the VAS container. To do this, a service terminal requires an internal authentication of the VAS container:
  • the service terminal checks the answer and breaks in the event of an error (with
  • a dealer terminal (which does not have the KGK AUT ) can indirectly determine the authenticity of the VAS container by checking the authenticity of VAS application A.
  • a VAS application can only be loaded at a service terminal that checked the authenticity of the VAS container during the loading process.
  • the authenticity of the VAS-application A can be attributed to the test of the middlerterminals whether the VAS-container KLVASP the key K or R p for the AS VAS-application A contains.
  • the dealer terminal can check this, for example, by:
  • VAS application A To test whether a VAS application A is loaded in the VAS container, it can be selected on a trial basis; Based on the error message of the SELECT FILE reply message, it can be concluded that it does not exist.
  • a selection of a VAS application of the implementation class EFJTRANSFER results implicitly from the operation View VAS applications and the storage of the data in the terminal. Since the terminal knows the record number of every object displayed from EFJTRANSFER, any object can be selected for further processing by reference to the record number.
  • the View VAS applications operation lists all VAS applications of the implementation classes DFJPT, DF_AD and EFJTRANSFER at a service terminal.
  • DFJPT implementation class
  • DF_AD implementation class EFJTRANSFER
  • EFJTRANSFER optionally applications of implementation class DF_PT or DF_AD, for which the dealer terminal has read rights
  • the cardholder inserts a VAS card (chip card with a valid VAS container) into the terminal.
  • VAS card chip card with a valid VAS container
  • the service terminal checks whether a VAS container is available:
  • the validity of the VAS container is checked.
  • the service terminal requires an internal authentication of the VAS container: • INTERNAL AUTHENTICATE ⁇ random number, KID of K AUT >
  • the service terminal checks the answer and terminates in the event of an error (with an error message).
  • the service terminal offers the cardholder several options to choose from. One of them is VAS applications. The cardholder selects these.
  • the service terminal authenticates itself:
  • VAS applications of the implementation classes DF_PT and DF_AD the individual VAS are successively controlled via the content of EFJDIR.
  • PIX A appears in the reply message, which is "00..00" if no VAS application is loaded in the corresponding DF.
  • a SEEK command can also be used.
  • the dealer terminal can request authentication (at least one) of the VAS application instead of the internal authentication. As mentioned, this is done by knowing the card of the corresponding K RVAS P or K VAS P key.
  • the content (or part of it according to R&R) of the EFJTRANSFER of each record is listed one after the other, as previously described.
  • VAS applications The operation interpreting VAS applications is analogous to this.
  • the terminal provides the cardholder with an option to interpret VAS applications.
  • data from EFJNFO and EFJVALUE can also be interpreted by the VAS provider (eg externally encrypted data) and data from EFJNTERNAL (e.g. miles from previous years at Miles & More).
  • VAS provider eg externally encrypted data
  • EFJNTERNAL e.g. miles from previous years at Miles & More
  • the key K LVASP (external authentication) is required to read the EFJNTERNAL of a VAS application.
  • the corresponding keys of the VAS provider are required for externally encrypted data within the elementary files EFJNFO, EFJNTERN and EFJVALUE as well as the transfer memory EFJTRANSFER.
  • the terminal program can easily decide for which applications keys are available for interpreting the data.
  • the operation Transfer of VAS applications means transferring all or selected VAS operations from a source card to a target card at a service terminal.
  • the condition here is that no VAS applications are loaded in the VAS container of the target card and that all VAS applications are deleted after the transfer to the source card. Both can be achieved by successively applying the Delete a VAS application operation.
  • the authenticity of the VAS cards must be checked and the target card must have sufficient storage space.
  • the operation transfer itself is essentially based on an expansion of the operation viewing VAS applications, in which the data from EFJNTERNAL and the keys KLVASP ur > d K RVASP are also read, and a repeated application of the operation loading a VAS application.
  • the VAS container ID is also transferred to the target card so that VAS applications on the target card behave exactly as on the source card.
  • the reason for this is that keys derived from a VAS provider are based on the VAS container ID, but the keys are copied unchanged.
  • a VAS provider does not want to change its accounting in the background system because it usually identifies VAS cards using the VAS container ID. It is essential to note the Transmission of the VAS container ID so that this system-wide unique number is deleted from the source card.
  • the service terminal In order to be able to read the elementary file EFJNTERNAL and the keys K LVA SP and K RVASP in particular , the service terminal overwrites the keys K LV ASP un after an external authentication with the key K so (similar to the operation deleting a VAS application) d can then transfer the data from EFJNTERNAL after a new authentication with K LV ASP.
  • the file EFJTRANSFER must also be transferred.
  • the Remove operation removes objects in this implementation class that have not already been marked as removed or expired, checks their signature with KSIG_VASC and transfers them to the EFJTRANSFER of the target card. However, the objects on the target card are marked as not removed so that they remain valid.
  • the global data of the VAS container must be transferred.
  • the sequence counter of the target card must be set to the value of the source card.
  • a VAS provider should write data to a VAS application A of the implementation class DF_PT or DF_AD.
  • Procedure for applying VAS data 1. The cardholder inserts a VAS card into a dealer terminal. - C ⁇ > -
  • the dealer terminal checks whether a VAS container is available:
  • dealer terminal itself is in possession of the KGK AUT master key, it may require internal authentication of the VAS container:
  • a dealer terminal (which does not have the KGK AUT ) can indirectly
  • VAS application A Verify the authenticity of the VAS container by checking the authenticity of VAS application A.
  • a VAS application can only be loaded at a service terminal that checked the authenticity of the VAS container during the loading process. The authenticity check of the VAS application A can be traced back to the test of the dealer terminal whether the VAS container is the key
  • KLVASP ° he contains the K RVA SP for VAS application A.
  • the dealer terminal can check this, for example, by:
  • the dealer terminal checks the answer and terminates in the event of an error (with an error message). - 6 - 4.
  • the dealer terminal selects VAS application A, authenticates itself and describes the elementary files that are necessary for processing the transaction:
  • a VAS provider does not have to use a proprietary file structure DF_X for its application.
  • the result is that a cardholder does not have to go to a service terminal to load a VAS application before using a VAS application voucher.
  • he can issue a voucher or receipt directly at the dealer terminal and have it reimbursed at another terminal (by removing the operation) or simply present the voucher or receipt (by reading).
  • Applying VAS data implicitly loads VAS applications of implementation class EFJTRANSFER.
  • the implementation class EFJTRANSFER exists for this application class, which consists of individual objects of the Art Record type. An entry in EFJTRANSFER is only possible with the TRANSFER command. To do this, the dealer terminal must have a valid K DEC validator key and a PIX A from VAS application A.
  • the cardholder inserts a VAS card into a dealer terminal.
  • the dealer terminal checks whether a VAS container is available: • SELECT FILE ⁇ AID VAS (error message if VAS container cannot be selected)
  • the dealer terminal reads the sequence number, which is also included in the MAC from step 4:
  • the dealer terminal can check whether the VAS container is genuine (ie has the shared secret K DEC ) by checking the response message from the TRANSFER command. We also refer to the previously described response message from the TRANSFER command.
  • a VAS provider can generate a right (e.g. voucher or receipt) by a validation process with the TRANSFER command in the EFJTRANSFER transfer field, which can be used by another VAS provider.
  • Data from the EFJVALUE or EFJNFO of the VAS application A of the devaluing VAS provider are validated.
  • the cardholder acquires the right in the form of an object in EFJTRANSFER.
  • the cardholder inserts a VAS card into a dealer terminal.
  • the dealer terminal checks whether a VAS container is available:
  • the dealer terminal reads the sequence number, which is also included in the MAC from step 4:
  • the dealer terminal uses the TRANSFER command to validate the data from EFJVALUE or EFJNFO.
  • the composition of the TRANSFER command message has already been described.
  • the terminal is authorized to validate if it can form a correct signature for the data with the key K DEC . This is checked by the VAS container.
  • the VAS container creates a record in EFJTRANSFER and the sequence number is incremented.
  • the dealer terminal can check whether the VAS container is genuine (ie has the shared secret K DEC ) by checking the response message from the TRANSFER command. And now the procedure for validating VAS data.
  • VAS data for VAS applications of implementation class DF_PT or DF_AD can be devalued by the associated VAS provider through the operation devalue, i.e. Acquire VAS data through validation. This consumes one value, creating a potential right to another value.
  • VAS data can be extracted from the EFJTRANSFER once with the supplementary command TAKE.
  • the entitlement is used up and the data remains in the transfer field for any further use (e.g. a refunded ticket is still required for the return trip) until it is overwritten by other objects if necessary.
  • the cardholder inserts a VAS card into a dealer terminal.
  • the dealer terminal checks whether a VAS container is available:
  • the dealer terminal reads out the available objects from EFJTRANSFER with the special case of the operation View VAS applications to decide whether a searched object is contained. Alternatively, you can search for a pattern with the SEEK command. If successful, the terminal knows number i of the record you are looking for. -> -
  • the terminal marks the record with record number i as removed by transmitting i, a random number calculated by it, its PIX and Terminal ID with the command TAKE:
  • the dealer terminal uses the TAKE command to read the data from the EFJTRANSFER while marking the data as removed.
  • the execution of the command additionally generates two different cryptograms C 1 and C 2 .
  • the cryptogram C- is calculated by the VAS container with the key KSIG_VASC.
  • the submitter of the extracted object signed with C ⁇ can have the system operator prove its uniqueness and authenticity.
  • the uniqueness and authenticity of the transaction results from the cryptogram of the VAS provider from which the object originally originated (and which was checked by the card, see TRANSFER), and the keeping of a sequence counter about the transactions and the cryptogram C 1 by Card on withdrawal.
  • the cryptogram C 2 is calculated by the VAS container with the key K DEC , which is derived from the VAS container from KGK DEC , PIX and Terminal ID.
  • K DEC the key that is derived from the VAS container from KGK DEC , PIX and Terminal ID.
  • the VAS container can directly prove the authenticity of the VAS container to the terminal. Since the TRANSFER command also checks that only real vouchers or receipts are saved in a real VAS container, the authenticity of the removed object can be inferred from this. Since C 2 is formed indirectly via the sequence number, the removed bit and the VAS container ID, the VAS container can even prove to the terminal that the removed object is unique.
  • the cardholder can change the PIN of the VAS container by knowing the PIN and can be reset by the system operator using external authentication by K s0 .
  • Non-numeric characters or character strings of any length can also be used as PIN or password.

Abstract

Chipkarte, die zur Durchführung von Transaktionen dient, bei denen geldwerte Einheiten oder andere nicht-monetäre Ansprüche repräsentierende Wertdaten zwischen dem Karteninhaber und mindestens einem Transaktionspartner (Service-Provider) übertragen oder dem Service-Provider zur Verifizierung der Ansprüche vorgewiesen werden, wobei die Chipkarte einen Speicher umfaßt, in dem zur Durchführung der Transaktionen erforderliche Daten abgespeichert werden, und die Chipkarte ferner folgendes aufweist: eine Einrichtung zum Laden von einer oder mehreren Kartenanwendungen (VAS-Applikationen) auf die Karte, die jeweils die Durchführung von Transaktionen zwischen dem Karteninhaber und einem oder mehreren Service-Provider ermöglichen.

Description

Chipkarte und Verfahren zur Verwendung der Chipkarte
Die Erfindung betrifft eine Chipkarte, ein Terminal zur Verwendung mit einer Chipkarte, ein Verfahren zur Verwendung der Chipkarte sowie ein Chipkartensystem.
Es sind bereits Mikroprozessor-Chipkarten mit Zahlungsfunktion, z.B. elektronische Geldbörsen, ec-Cash, Kreditfunktion usw., im Einsatz und es sind je nach Ausprägung durch Organisationen, wie ZKA (Zentraler Kreditausschuß), VISA oder EMV (Europay Mastercard VISA), Vorgaben festgelegt, so daß sie als Zahlungsmittel („Geldersatz") verwendet werden können. Als beispielhafte Beschreibungen seien hier genannt:
- ZKA, Zentraler Kreditausschuß, "Schnittstellenspezifikation für die ec-Karte mit Chip", 27.10.1995;
- Europay International, "Integrated Circuit Card, Specification for 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;
Ein aktueller Überblick über Chipkarten ist zu finden in:
- Stefan Schutt, Bert Kohlgraf: "Chipkarten, Technische Merkmale, Normung, Einsatzgebiete", R. Oldenbourg Verlag, München/Wien, 1996, ISBN 3-486- 23738-1. Herkömmliche Chipkarten sind regelmäßig nur für einen bestimmten Anwendungszweck, beispielsweise als elektronische Geldbörse oder als elektronischer Ausweis, nutzbar. Die auf diesen Chipkarten aufgebrachten Anwendungen sind jedoch regelmäßig statisch, d.h. sie werden bei der Herstellung der Chipkarte aufgebracht und bleiben über den Lebenszyklus der Karte hinweg unverändert bestehen.
Herkömmliche Chipkarten sind also sowohl hinsichtlich ihrer Variabilität als auch hinsichtlich ihrer Funktionalität beschränkt. Insbesondere sind herkömmliche Chipkarten nach dem Herstellungsprozeß hinsichtlich ihrer Funktionalität festgelegt und nicht mehr veränderbar.
Es ist daher eine Aufgabe der vorliegenden Erfindung, eine Chipkarte zu schaffen, deren Funktionalität variabel ist.
Eine weitere Aufgabe der Erfindung besteht darin, eine Chipkarte zu schaffen, bei der die Zahl und Art der mit der Chipkarte durchführbaren Applikationen bzw. Anwendungen und Transaktionen auch nach dem Herstellungsprozeß noch variabel ist. Es soll möglich sein, auf diese Chipkarte zusätzliche Applikationen "zu laden", es sollen Applikationen von der Chipkarte gelöscht werden können und die einzelnen Applikationen sollen daten- und sicherheitstechnisch unabhängig voneinander definiert sein und unabhängig voneinander ablaufen.
Die Chipkarte soll beispielsweise die daten- und sicherheitstechnischen Voraussetzungen nach ISO 7816 erfüllen; die einzelnen Applikationen der Karte sollen jedoch insbesondere von der Kartenplattform selbst unabhängig sein.
Es ist eine weitere Aufgabe der Erfindung, eine Chipkarte zu schaffen, bei der der Benutzer die Anzahl und Art der in seiner Karte verfügbaren Applikationen selbst bestimmen bzw. zusammenstellen und ändern kann. Es ist ferner eine Aufgabe der vorliegenden Erfindung, eine Chipkarte zu schaffen, mit der sowohl Intraservices (d.h. geschlossene Applikationen in dem Sinne, daß keine Abrechnung und Leistungsübertragung mit externen Partnern zu erfolgen hat) als auch Interservices (d.h. Applikationen mit zusätzlichen Außenbeziehungen zu externen Partnern) ermöglicht und durchgeführt werden können.
Gemäß einem Aspekt der Erfindung ist eine Einrichtung vorgesehen, mit der eine oder mehrere Kartenanwendungen auf die Karte geladen werden können, mit denen jeweils die Durchführung von Transaktionen zwischen dem Karteninhaber und einem oder mehreren Service-Providern ermöglicht wird.
Durch das Laden wird die Chipkarte so konfiguriert, daß sie eine neue Funktionalität erhält, d.h. eine Applikation ausführen kann, die ihr bisher nicht möglich war. Durch die geladenen Daten werden Applikationen definiert und in Verbindung mit den Grundfunktionalitäten der Karte wie etwa dem Betriebssystem realisiert, die vorher nicht auf der Karte vorhanden waren. Damit wird die Funktionalität der Karte durch das Laden einer Applikation um eben diese Applikation erweitert.
Gemäß einem Ausführungsbeispiel der Erfindung ist auf der erfindungsgemäßen Chipkarte eine Datenstruktur (DF_VAS) vorgesehen, die selbst wiederum in eine Teilstruktur und einen Definitionsdatensatz unterteilt ist, wobei die Datenstruktur mittels einer sie identifizierenden Kennung eindeutig identifiziert ist und somit von der Kartenplattform an sich unabhängig ist. In die Teilstruktur können nun sogenannte Applikationen geladen werden, d.h. Funktionalitäten oder Anwendungen der Chipkarte. Damit wird es durch Laden einer bestimmten Applikation der Chipkarte möglich, Transaktionen zwischen dem Karteninhaber und einem für diese Applikation spezifischen Service-Provider durchzuführen. Ein Definitionsdatensatz innerhalb der Datenstruktur enthält Informationen über die Art und/oder die Struktur der in der Teilstruktur geladenen Applikationen. Zumindest der Definitionsdatensatz, vorzugsweise jedoch die gesamte Datenstruktur sind mittels mindestens eines Systemschlüssels gegen Modifikationen abgesichert und - M nur unter Verwendung dieses Schlüssels modifizierbar. Anstelle eines Systemschlüssels sind auch andere Sicherungsmechanismen oder Sicherungseinrichtungen vorstellbar, mittels derer die Absicherung gegen Modifikationen erfolgen kann, etwa durch eine persönliche Kennziffer (PIN) oder sonstige zur Absicherung dienende Einrichtungen.
Mit der obigen Struktur ist es möglich, in die Teilstruktur verschiedene Applikationen zu laden und diese auch wieder aus der Teilstruktur zu löschen, so daß die Karte hinsichtlich ihrer Funktionalitäten bzw. der mit ihr durchführbaren Anwendungen variabel ist. Laden und Löschen von Applikationen geschieht durch Schreiben von applikationsspezifischen Daten und Schlüsseln in die vorhandene Teilstruktur. Durch Vorsehen des Systemschlüssels und der Datenstrukturkennung wird die die Multifunktionalität ermöglichende Datenstruktur unabhängig von der Kartenplattform an sich und auch hinsichtlich ihrer Sicherheitsarchitektur selbsttragend und unabhängig von der Kartenplattform.
Abhängig von den in der Teilstruktur geladenen Applikationen können dann mittels der Karte Transaktionen zwischen dem Karteninhaber und Service-Providern, die von den geladenen Applikationen abhängig sind, durchgeführt werden.
Vorzugsweise weist die Chipkarte ferner einen Transfer-Speicherbereich auf, in den die bei der Durchführung von Transaktionen auszutauschenden Daten geschrieben bzw. aus dem sie gelesen werden. Indem für das Entnehmen von Daten aus dem Transfer-Speicherbereich terminalspezifische Schlüssel vorgesehen werden, sind die einzelnen Zugriffe sicherheitstechnisch voneinander unabhängig.
Die einzelnen in der Karte vorhandenen Teilstrukturen bzw. Applikationen sind vorzugsweise voneinander unabhängig und jeweils einem bestimmten Service- Provider zugeordnet. Sie stellen sozusagen die für diesen Service-Provider proprietären oder spezifischen Daten zum Durchführen einer bestimmten Applikation dar. Sie enthalten deshalb je nach Applikationstyp und je nach Service- - ≤*-
Provider unterschiedliche Informationen, beispielsweise Daten, die einen bestimmten Wert repräsentieren (Bonuspunkte, Kontostand, etc.), Informationsdaten über die Applikation, Informationsdaten über den Service- Provider, etc. Vorzugsweise enthalten sie jedoch insbesondere auch für die Applikation spezifische Schlüssel, mittels derer ein Zugriff auf die Daten der Teilstruktur auf sicherheitstechnisch von anderen Teilstrukturen unabhängige Art und Weise ermöglicht wird. Das Laden oder Generieren der Teilstruktur bzw. Applikation selbst ist dagegen mit zumindest einem übergeordneten Systemschlüssel abgesichert.
Vorzugsweise findet vor dem Durchführen einer Transaktion eine gegenseitige Authentifizierung zwischen Chipkarte und einem Terminal statt, wobei dabei ein applikations- bzw. teilstrukturspezifischer Authentifizierungsschlüssel vorgesehen ist.
Zum Durchführen von Transaktionen werden dann Daten in eine für die jeweilige VAS-Applikation reservierte Teilstruktur geschrieben oder daraus gelesen oder über den Transfer-Speicherbereich abgewickelt. Im ersten Fall werden applikationsspezifische Schlüssel verwendet. Im letzteren Fall wird ein applikationsspezifischer und vorzugsweise auch ein terminalspezifischer Schlüssel, der beispielsweise mittels eines Schlüssel-Erzeugungsschlüssels, der auf der Karte vorgesehen ist und aus applikationsspezifischen Daten generiert wird, verwendet. Die so in den Transferspeicher geschriebenen Daten können dann vom Service- Provider über das Terminal entnommen werden, was vorzugsweise durch Kennzeichnen der im Transferspeicher gespeicherten Daten als entwertet geschieht. Handelt es sich dabei um einen Service-Provider, der nicht für die schreibende Applikation spezifisch ist, so wird dadurch ein sogenannter Interservice ausgeführt, d.h. es werden zum Nutzen bzw. auf Kosten des Karteninhabers geldwerte Daten zwischen unterschiedlichen Service-Providern ausgetauscht. Als zusätzliche Sicherung ist ferner eine PIN oder ein Paßwort zur Verifikation der Berechtigung eines Transaktionsvorgangs vorgesehen.
Durch die variable Struktur der Karte können zu verschiedenen Zeitpunkten verschiedene Applikationen in unterschiedlicher Anzahl auf der Karte untergebracht sein.
Die Echtheit von aus dem Transfer-Speicher entnommenen Daten wird vorzugsweise unter Verwendung eines Signierschlüssels bzw. unter Verwendung einer digitalen Unterschrift oder mindestens eines Schlüssels gesichert. Besonders vorteilhaft ist es dabei, wenn die entnommenen Daten weiter im Transfer-Speicher verbleiben, jedoch lediglich durch die Karte als entnommen gekennzeichnet werden. Dadurch können auch nach der Transaktion noch Informationen über die durchgeführte Transaktion erhalten werden. Damit und mit der Absicherung der Entnahme ist auch Einmaligkeit nachweisbar.
Besonders vorteilhaft ist es ferner, wenn die in den Transfer-Speicher geschriebenen Daten mit einem Verfallsdatum gekennzeichnet sind, nach dem sie ihren Wert verlieren. Dadurch werden Applikationen realisierbar, die beispielsweise die Bereitstellung eines für einen bestimmten Zeitraum gültigen Tickets ermöglichen.
Mittels eines vorzugsweise vorgesehenen Transaktionszählers können die Transaktionsdaten bzw. die Wertdaten hinsichtlich ihrer zugehörigen Transaktion eindeutig bestimmt und identifiziert werden.
Die erfindungsgemäße Chipkarte besteht in einer vorteilhaften Ausführungsform also aus einem hierarchischen Speicherkonzept, das auf seinen unterschiedlichen Ebenen mittels verschiedener Schlüssel gegen Modifikationen abgesichert ist, das auf der Ebene der Applikationen hinsichtlich der in den Speicher geladenen Applikationen variabel ist, wobei jede einzelne Applikation durch eigene spezifische Schlüssel gegenüber anderen abgesichert und von diesen unabhängig ist, und wobei die Gesamtstruktur mittels mindestens eines Systemsschlüssels und mittels einer die Struktur identifizierenden Kennung gesichert und von der Kartenplattform selbst unabhängig ist. Das Konzept des Transferspeichers ermöglicht den Austausch von Daten sowohl zwischen Karteninhaber und Service-Provider als auch zwischen unterschiedlichen Service-Providern selbst. Auch das Lesen und Schreiben in den bzw. aus dem Transferspeicher ist durch Schlüssel abgesichert, wobei diese ebenfalls karten- und appplikationsspezifisch, zusätzlich jedoch auch noch terminalspezifisch sind. Eine Authentifizierung, die vor jeder Transaktion durchgeführt wird, sowie optional eine PIN oder ein Paßwort erhöhen zusätzlich die Sicherheit der erfindungsgemäßen Chipkarte.
In den Patentansprüchen 21 bis 30 wird ein Terminal zur Verwendung mit der erfindungsgemäßen Chipkarte definiert. Dieses Terminal dient zum Laden oder Löschen von Applikationen, zur Durchführung von Transaktionen, zum Ansehen von Daten sowie zur Durchführung von weiteren in Verbindung mit den jeweiligen Applikationen und Transaktionen stehenden Funktionen. Ein Verfahren zum Durchführen von Transaktionen zwischen Karteninhaber und Service-Provider ist in den Ansprüchen 31 bis 33 definiert, das Laden von Daten auf eine erfindungsgemäße Chipkarte definieren Ansprüche 34 und 35, und Anspruch 36 definiert ein Gesamtsystem aus Chipkarte und Terminal.
Nachfolgend wird die vorliegende Erfindung anhand eines bevorzugten Ausführungsbeispiels näher beschrieben, wobei Bezug auf die beiliegenden Zeichnungen genommen wird. Dabei zeigen
Fig. 1 schematisch die erfindungsgemäße Chipkarte,
Fig. 2 eine schematische Darstellung des Gesamtsystems der Komponenten der Erfindung,
Fig. 3 den Datenfluß im Gesamtsystem, - s -
Fig. 4 die möglichen Applikationsklassen und Operationen durch ein Transaktionsmodell in schematischer Darstellung,
Fig. 5 eine schematische Darstellung der Sicherheitsarchitektur der erfindungsgemäßen Chipkarte,
Fig. 6 die Dateistruktur einer allgemeinen Implementierungsklasse des VAS- Containers,
Fig. 7 verschiedene Implementierungsklassen des VAS-Containers gemäß einem Ausführungsbeispiel der vorliegenden Erfindung,
Fig. 8 die Dateistruktur des VAS-Containers gemäß einem Ausführungsbeispiel der vorliegenden Erfindung,
Fig. 9 schematisch die Dateistruktur der Implementierungsklasse DF_PT,
Fig. 10 schematisch die Dateistruktur der Implementierungsklasse DF_AD.
Bevor die Erfindung näher beschrieben wird, sollen einige, im nachfolgenden verwendeten Begriffe definiert werden:
VAS: Value Added Services
VAS-Karte: Die VAS-Karte ist eine Chipkarte, mit der an den Value Added Services teilgenommen werden kann. Die VAS-Karte enthält neben anderen Anwendungen wie z.B. Zahlungsapplikationen (also elektronische Geldbörse) den VAS-Container.
VAS-Container: Der VAS-Container beinhaltet Datenstrukturen, Zugriffsbedingungen, Schlüssel und (Ergänzungs-) Kommandos zum Verwalten von VAS-Applikationen und der Bereitstellung der Funktionalität der VAS- Applikationen. VAS-Applikation: VAS-Applikationen enthalten VAS-Daten. Zugriff auf die VAS- Daten wird durch die VAS-Applikation gesteuert. Ein VAS-Provider betreibt im VAS-Container eine oder mehrere VAS-Applikationen. Die Nutzung der VAS- Applikation definiert sich aus dem Aufbringen, Lesen und Verarbeiten von VAS- Daten. Eine VAS-Applikation kann entweder als Intra- oder Interservice ausgeprägt sein.
VAS-Provider: Der VAS-Provider ist für seine VAS-Applikation verantwortlich, die er nach Rahmenbedingungen des System Operators und nach seinen eigenen Vorstellungen entwickelt und danach über den System Operator und die Terminals den Cardholders zur Verwendung bereitstellt. Die VAS-Applikationen sind in den VAS-Container der VAS-Karte zu laden, bevor daran teilgenommen werden kann.
Intraservice: Intraservice ist eine Sorte von VAS-Applikation, die unter exklusiver Regie des jeweiligen VAS-Providers benutzt wird. Intraservice Applikationen sind geschlossene Applikationen in dem Sinne, daß keine Abrechnung oder Leistungsübertragung mit externen Partnern erfolgt. Eine VAS-Applikation kann entweder als Intra- oder Interservice ausgeprägt sein.
Interservices: Interservice Applikationen sind Intraservice Applikationen, die über zusätzliche Außenbeziehungen zu externen Partnern unterhalten. Eine VAS- Applikation kann entweder als Intra- oder Interservice ausgeprägt sein.
SO, System Operator: Der System Operator, oder System Betreiber, bietet den VAS-Providern und den Cardholders das VAS-System zur Nutzung an.
Issuer: Der Issuer, oder Kartenherausgeber, bringt die VAS-Karten mit VAS- Container in den Umlauf.
CH, Cardholder: Der Cardholder, oder Karteninhaber, ist die Person, die die Karte (hier: VAS-Karte) besitzt und einsetzt, um an den Value Added Services _ ^ o - teilzunehmen. Diese Person ist nicht zwangsläufig der eigentliche Eigentümer der
Karte.
Serviceterminal: Das Serviceterminal wird vom System Operator für VAS- Applikationen aufgestellt. Am Serviceterminal kann der Karteninhaber die VAS- Applikationen auf seiner VAS-Karte verwalten (Laden, Ansehen, Löschen und Übertragen von VAS-Applikationen).
Händlerterminal: Das Händlerterminal besitzt Zahlungsfunktionen und bietet zusätzlich VAS-Funktionalität. An ihm setzt der Karteninhaber seine VAS-Karte ein, um einerseits zu bezahlen und gleichzeitig an den Vorteilen von VAS teilzunehmen.
AID: (Application Identifier) maximal 16 Byte langer Name von Applikationen zur eindeutigen Unterscheidung von Applikationen und der Applikationsselektion von außen ohne Kenntnis der Dateistruktur einer Karte. Die AID besteht aus einer 5 Byte langen Registered Application Provider ID (RID) und optional aus einer maximal 11 Byte langen Proprietary Application Identifier Registration (PIX).
DF: Directory File nach ISO 7816
EF: Elementary File nach ISO 7816
Gültiger VAS-Container: VAS-Container, der sich gegenüber der externen Welt authentisieren kann.
KID: (Key Identifier) Nummer eines Schlüssels innerhalb eines Elementary Files, das Schlüssel enthält
R&R: Rules and Regulations
p: Maximale Zahl von Objekten der Implementierungsklasse DF_PT - A λ - a: Maximale Zahl von Objekten der Implementierungsklasse DF_AD
nrDIR: Maximale Gesamtzahl von Objekten: nrD|R = p + a Die Anzahl von Records in EF_DIR ist nrD|R.
nr EF_τRANSFER- Anzahl von Records des EF_TRANSFER
Fig. 1 zeigt schematisch die Struktur der erfindungsgemäßen Chipkarte. Zusätzlich zu den statisch und nicht veränderbaren, beim Herstellungsprozeß aufgebrachten Daten wie dem Masterfile MF und der (optional vorhandenen) Geldbörsenfunktion DF_Börse ist auf der erfindungsgemäßen Karte noch ein Verzeichnis bzw. eine Datenstruktur oder Dateistruktur DF_VAS vorgesehen. Diese dient zur Aufnahme von Zusatzfunktionalitäten, sogenannten Value Added Services VAS. Aufgrund dieser Zusatzfunktionalitäten, die Applikationen darstellen, die auch noch zu einem späteren Zeitpunkt, also nach der Herstellung der Karte, auf die Karte geladen werden können, ist die Karte hinsichtlich ihrer Funktionalitäten und der mit ihr durchführbaren Transaktionen flexibel und variabel. Der auf der erfindungsgemäßen Chipkarte vorgesehene sogenannte VAS-Container (DF_VAS) ermöglicht die Variabilität und Flexibilität der Chipkarte bezüglich ihrer Funktionen und löst daneben die auf der Chipkarte untergebrachten Applikationen sicherheitstechnisch von der Kartenplattform, so daß diese von der Kartenplattform unabhängig sind und eventuell sogar auf eine andere Karte übertragen werden können.
Die erfindungsgemäßen, neuen Zusatzfunktionalitäten (Value Added Services, VAS) werden realisiert durch Mikroprozessor-Chipkarten. Die Umsetzung dieser Zusatzfunktionalitäten wird durch den VAS-Container realisiert. Der VAS-Container auf der Mikroprozessor-Chipkarte bildet die Plattform zur Aufnahme der VAS- Applikationen. Die VAS-Applikationen sind die jeweiligen Realisierungen bestimmter Zusatzfunktionalitäten. lm Fall der elektronischen Geldbörse wird das Bezahlen mit der Karte (Zahlungsfunktion) und die Nutzung einer VAS-Applikation (Zusatzfunktionalität) über getrennte Mechanismen abgewickelt; aus Sicht des Kartennutzers bzw. Karteninhabers kann dies aber als ein Vorgang erscheinen.
Die Mikroprozessor-Chipkarte wird erweitert um den VAS-Container, der verschiedene und unabhängige Applikationen aufnehmen kann. Er stellt Funktionen zum Aufbringen, Löschen und Übertragen dieser Applikationen zur Verfügung; diese können nur vom autorisierten Systembetreiber verwendet werden. Der VAS-Container ist daten- und sicherheitstechnisch unabhängig von anderen Systemkomponenten auf dem Mikroprozessor-Chip. Der VAS-Container ist vollständig durch sich selbst definiert und allein funktionsfähig. Für ihn ist eine unabhängige Sicherheitsarchitektur definiert, so daß VAS-Applikationen eigenständige Sicherheitsfunktionen verwenden. Die Sicherheitsarchitektur verwendet kartenspezifische Schlüssel, die nicht herstellerspezifisch und die unabhängig von Identifikationsmerkmalen der Kartenplattform sind.
Der VAS-Container verwendet auch Mechanismen zur Ableitung terminalspezifischer Schlüssel. Mit diesen kann der VAS-Container selbst aktiv die Echtheit von Terminals bzw. die von ihnen erzeugten Daten prüfen.
Im VAS-Container werden die VAS-Applikationen abgelegt, die über Mechanismen des VAS-Container Daten bereitstellen und dadurch die Steuerung der zugeordneten Schnittstellen bewerkstelligen. Der VAS-Container ermöglicht und steuert auch den sicheren Austausch von Daten für Interservices zwischen Partnern. Der VAS-Container erledigt aktiv die Kontrolle, d.h. die Echtheit und die Einmaligkeit, der übertragenen Datenwerte.
Ein Vorteil des VAS-Container gegenüber anderen Ansätzen von Multi- Applikations-Karten ist, daß dieses Konzept unabhängig von einer bestimmten
Kartenplattform ist. Es bietet eine Sicherheitsarchitektur, die unabhängig von plattformspezifischen Sicherheitsmechanismen (wie Schlüssel,
Identifizierungsdaten, PIN, Signaturverfahren) ist.
Ein weiterer Vorteil des Konzeptes VAS-Container ist, daß die Anzahl der verschiedenen Applikationen auf der Karte nicht fest vorgegeben ist durch Beschränkungen und Vorgaben zum Zeitpunkt der Kartenherstellung oder der Kartenausgabe; die aktuelle Kartenbelegung mit Anwendungen ist frei wählbar durch den Kartennutzer und ist nur durch den auf der jeweiligen Karte zur Verfügung stehenden Speicherplatz beschränkt. Die Anzahl der aktuell auf einer Karte geladenen VAS-Applikationen hängt vom tatsächlichen Gebrauch der Karte ab. Der Kartennutzer stellt individuell die VAS-Applikationen auf seiner Karte zusammen; dies beinhaltet auch die Änderung der Zusammenstellung zu einem späteren Zeitpunkt. Der VAS-Container ermöglicht eine multifunktionale Karte, bei der die Kartenfunktionalität während des Lebenszyklus der Karte variabel in Anzahl und Art der Anwendungen zusammengestellt und verwendet werden kann. Es können so auch Anwendungen, für die bislang einzelne, spezielle Karten notwendig waren, auf nur einer Karte abgelegt werden und zum Einsatz kommen. VAS-Applikationen können auch auf andere Karten übertragen werden. Damit können VAS-Applikationen den Lebenszyklus einer Karte überleben; sie begleiten den Kartennutzer während des Lebenszyklus der Anwendungen.
Die Mikroprozessor-Chipkarte mit Zusatzdiensten ist ein geeignetes Medium zur Verbreitung und zur Vermarktung von Dienstleistungen, bei denen auf geschützte Daten zugegriffen werden muß. Diese Mikroprozessor-Chipkarte kann als Zahlungsmittel, Recheneinheit und zur Wertaufbewahrung verwendet werden. Sie kann entsprechend dem Kundenwunsch vom Kunden selbst und nach Kartenausgabe flexibel mit Zusatzdiensten versehen und zu deren Steuerung herangezogen werden. Sie kontrolliert auch aktiv die Authentizität von beteiligten Terminals und stellt die Einmaligkeit und Echtheit von übergebenen Daten sicher.
Fig. 2 zeigt eine Systemübersicht. Darin dargestellt sind die Systemkomponenten. Ein Systembetreiber (System Operator) stellt das System zur Verfügung. An Serviceterminals (ST) können VAS-Applikationen geladen, gelöscht und übertragen werden; weitere Operationen sind: VAS-Applikation auswählen, ansehen, interpretieren usw.
Die Anbieter von VAS-Applikationen, die sogenannten VAS-Provider, entwerfen eigene VAS-Applikationen nach den Rahmenbedingungen des Systembetreibers und, soweit möglich, nach eigenen Vorstellungen. Durch Abschluß mit einer digitalen Unterschrift werden die entsprechenden Terminalprogramme auf Echtheit nachprüfbar.
Fig. 3 zeigt den Datenfluß im System.
Die VAS-Applikationen werden über den Systembetreiber an den Terminals den Kartennutzern zur Verwendung bereitgestellt. VAS-Applikationen sind in den VAS- Container der erfindungsgemäßen Chipkarte zu laden, bevor daran teilgenommen werden kann.
An Händlerterminals (HT) werden auf der Karte vorhandene VAS-Applikationen genutzt, indem VAS-Daten aufgebracht bzw. gelöscht werden.
Zur Realisierung der Mikroprozessor-Chipkarte mit VAS-Funktionalität wird neben anderen bestehenden Anwendungen (z.B. Zahlungsapplikationen wie die elektronische Geldbörse) der VAS-Container auf der Karte aufgebracht.
Der VAS-Container verwendet Funktionen, die ein Aufbringen, Löschen und Übertragen von VAS-Applikationen ermöglichen. Diese Verwaltungsfunktionen werden ausschließlich vom System Operator benutzt und sind in der Karte gegen Fremdbenutzung abgesichert. Der VAS-Container beinhaltet einen Transferspeicher, mit dem der Austausch von Daten zwischen VAS-Applikationen realisiert wird. Zur Steuerung des Transferspeichers werden zwei Kommandos TRANSFER und TAKE eingesetzt. Das Kommando TRANSFER erzeugt einen Eintrag im Transferspeicher mit für die jeweilige Applikation spezifischen Daten. Neben den Nutzdaten zählen hierzu auch die zur Steuerung der Verarbeitung notwendigen Angaben wie Datum, Verfallsdatum und Identifikationsdaten. Mit dem Kommando TAKE werden Objekte aus dem Transferspeicher entnommen und als entnommen markiert. Je nach Anwendungsfall werden die Objekte dann als weiterhin gültig oder als ungültig markiert. Übertragene Daten werden durch den VAS-Container auf Echtheit und Einmaligkeit überprüft.
VAS-Applikationen verwenden zur Bereitstellung und Steuerung der Anwendungen VAS-Daten. Zugriff auf die VAS-Daten wird durch die VAS-Applikation gesteuert, die sich dazu Mechanismen bedient, welche im VAS-Container allen Applikationen bereitgestellt sind. Ein VAS-Provider betreibt im VAS-Container eine oder mehrere VAS-Applikationen. Die Nutzung der VAS-Applikation definiert sich aus dem Aufbringen, Lesen und Verarbeiten von VAS-Daten.
Der VAS-Container unterstützt Interservices. Interservices erfordern Zugriff auf gemeinsame Daten, Übertragung von Leistungsansprüchen und die Abrechnung von Leistungen zwischen verschiedenen Partnern.
Im folgenden sollen die mit der erfmdungsgemäßen Chipkarte möglichen Dienste bzw. Applikationen anhand von Beispielen aufgezeigt werden.
Die Beschreibung bezieht sich jeweils auf die Erscheinungsweise und Funktion nach dem Stand der Technik. Die Funktion soll zukünftig durch eine oder mehrere VAS-Applikationen nachgebildet werden.
Als erstes werden Intraservices vorgestellt.
Beispiel A: Kundenclub Ein Kaufhaus betreibt einen Kundenclub. Der Kunde wird in diesem Club Mitglied und erhält mit diesem Status spezifische Clubleistungen, die Nichtmitglieder nicht erhalten können. Heute identifiziert sich ein Clubmitglied in der Clubumgebung durch einen Clubausweis. Der Clubausweis wird beim Eintritt erstellt, ist nicht übertragbar, und hat in der Regel eine Gültigkeitsdauer. Über den Clubausweis werden keine spezifischen Transaktionen abgewickelt, d.h. es besteht keine Kopplung mit dem Kundenumsatz. Damit grenzt sich der Clubausweis von Bonusprogrammen ab, in denen ein Zusammenhang Status / Umsatz besteht.
Analog: Großhändler Ausweis, Senator Card, Buchclub
Ziel: Die Clubzugehörigkeit soll durch eine Applikation im VAS-Container nachgewiesen werden.
Beispiel B: Bonussystem
Ein Kunde erhält für jede Transaktion einen Bonusanspruch vergütet. Der Bonusanspruch wird kumuliert und kann an einem durch den Kunden definierten Zeitpunkt für eine geldwerte Leistung eingetauscht werden. Der Bonusanspruch gilt für einen definierten Zeitraum und kann anonym oder personenbezogen verwaltet werden. Der Bonusanspruch entsteht durch Umsatz oder Nutzungshäufigkeit.
Analog: Punktestand von Miles & More
Ziel: Das Punktekonto soll durch eine Applikation im VAS-Container verwaltet werden.
Beispiel C: Rabatt
Der Kunde erhält Volumenrabatt nach Plan. Der Rabatt wird für jede einzelne Transaktion gewährt. Die Karte verwaltet keine Umsatzhistorie. Jede Transaktion ist in sich abgeschlossen. Ziel: Der Rabattanspruch soll durch eine VAS-Applikation ausgewiesen werden.
Beispiel D: Ausweisfunktion
Eine Person kann durch Merkmale in der Karte gegenüber Dritten nachweisen, daß Berechtigung zu bestimmten Leistungen besteht. Die Zugehörigkeit der Person zum Ausweis muß bei jeder Transaktion nachgewiesen werden (Lichtbild, PIN, Biometrik). Die Echtheit des Ausweises wird als Sicherheitsmerkmal herangezogen.
Analog: Internet Zugang, Zugang Homebanking, Telefonkarte
Ziel: Die Berechtigung soll durch eine VAS-Applikation nachgewiesen werden.
Beispiel E: Werteinheiten
Werteinheiten werden erworben und durch ein- oder mehrmalige Nutzung verbraucht. Pro Transaktion verringert sich der Wert um eine oder mehrere Einheiten. Die Nutzungsberechtigung ist übertragbar und kann Einschränkungen für die Nutzung beinhalten.
Analog: Einzelfahrschein, Streifenfahrschein, Abo-Konzertkarte, Squash- Zehnerkarte, Kino-Ticket, Telefoneinheiten
Ziel: Durch eine VAS-Applikation soll die Abwicklung rationalisiert werden.
Beispiel F: Nutzungsabrechnung - Λ 8 - Die Nutzung einer Leistung wird nach Zeit, Häufigkeit oder Menge registriert und nach Tarifplan abgerechnet. Im voraus ist nicht bekannt, in welchem Umfang die
Leistung abgerufen wird.
Analog: Verzehrbon, Kurzzeitparkschein
Ziel: Durch eine VAS-Applikation soll die Abrechnung nach Tarif ermöglicht werden. Die jeweils aktuell benötigten Abrechnungsdaten sollen im VAS- Container gespeichert sein.
Beispiel G: Merkzettel (Mobiler Datenspeicher)
Diese Applikation ermöglicht die Übergabe von Daten des Karteninhabers an den VAS-Provider. Dadurch werden Abläufe automatisiert, die derzeit noch manuell erfolgen. Aus diesen Daten läßt sich kein geldwerter Gegenwert ableiten.
Analog: Ausfüllen von Lottoscheinen, Einkaufszettel, Kassenzettel, Telefonregister
Ziel: Ein VAS-Provider soll die Daten der Karte entnehmen und so den entsprechenden Dienst direkt erbringen können (z.B. Telefonverbindung herstellen, gewünschte Waren zusammenstellen, elektronisch den Lottoschein ausfüllen und erfassen). Die Daten können sowohl kurzfristig als auch langfristig in der Karte gespeichert werden.
Nach diesen Beispielen für Intraservices sollen nun einige Beispiele für Interservices folgen.
Ein Interservice entsteht immer dann, wenn an einem Dienst mehrere VAS- Provider beteiligt sind. Dies ist untrennbar damit verbunden, daß Daten den
Bereich eines VAS-Provider verlassen. Heute geschieht dies über Bescheinigungen auf Papier. Beispiel A: Fahrpreiserstattung
Ein Kaufhaus erstattet einem Kunden den Fahrschein eines ÖPNV-Unternehmens für die Fahrt zum Kaufhaus. Der Kunde muß dem Kaufhaus den Einzelfahrschein vorlegen. Das Kaufhaus vermerkt auf dem Fahrschein, daß er erstattet wurde. Eventuell bekommt das Kaufhaus seinerseits einen Teil der Erstattung an den Kunden vom Verkehrsunternehmen zurück.
Ziel: Der Erstattungsvorgang soll elektronisch abgewickelt werden.
Beispiel B: Fahrgutschein
Ein Kaufhaus erstattet dem Kunden beim Warenkauf die Kosten für eine Heimfahrt, indem ein Gutschein ausgestellt wird. Der Kunde erhält an einem Fahrkartenschalter ein Ticket des ÖPNV bzw. zahlt einen geringeren Preis für das Ticket. Der Verkehrsbetrieb rechnet den Gutschein mit dem Kaufhaus ab.
Ziel: Abbildung der Mechanismen durch VAS-Applikationen mit elektronischer Abrechnung zwischen Handel und ÖPNV.
Beispiel C: Kundenparkplatz
Ein Kaufhaus erstattet dem Kunden einen Teil der Parkgebühren bei Benutzung eines bestimmten Parkhauses. Das Parkhaus wird durch ein unabhängiges Unternehmen betrieben und erhält vom Kaufhaus eine geldwerte Vergütung für jede Kundengutschrift.
Ziel: Abbildung der Mechanismen durch VAS-Applikationen mit elektronischer Abrechnung zwischen Handel und Parkhaus.
Beispiel D: Multilaterales Bonusprogramm - Z O- Eine Gruppe von Handelsunternehmen und Dienstleistern einigt sich auf ein gemeinsames Bonusprogramm.
Ziel: Jeder Partner kann Bonuspunkte auf einem gemeinsamen Konto auf der
Karte gutschreiben oder vergüten. Die Abrechnung der Leistungen zwischen den Partnern erfolgt durch das Hintergrundsystem.
Beispiel E: Anerkennung von Bonuspunkten zwischen Dienstleistern
Jeder Dienstleister betreibt ein eigenes Bonusprogramm, hat aber Absprachen mit anderen, gesammelte Punkte anzuerkennen. Bekannte Beispiele sind Absprachen zwischen Autovermietern und Fluggesellschaften zum Sammeln von „Meilen".
Ziel: Unterstützung der Übertragung von Bonuspunkten durch die Karte.
Jeder VAS-Provider soll zunächst seine Punkte für sich sammeln, ohne daß ein anderer eingreifen kann. Für die Übertragung sollen sichere Mechanismen bereitgestellt werden.
Beispiel F: Nachttaxi
Durch einen Fahrausweis des ÖPNV wird gleichzeitig die Berechtigung zur Fahrt im Sammeltaxi (z.B. nach 22.00 Uhr) erworben. Das Taxiunternehmen muß zur Abrechnung nachweisen, daß der Fahrausweis vorgelegen hat. Die Inanspruchnahme des Taxis wird auf der Karte vermerkt, um Mißbrauch zu unterbinden.
Ziel: Die VAS-Applikation soll die Inanspruchnahme, Kontrolle und
Verrechung dieses Dienstes ermöglichen.
Im folgenden soll der Aufbau der erfindungsgemäßen Chipkarte näher beschrieben werden. -2 Λ ~ Die Mikroprozessor-Chipkarte mit VAS-Funktionalität enthält insbesondere den VAS-Container.
Der VAS-Container ist eine eigenständige Anwendung und existiert entweder alleine oder auch parallel neben anderen Applikationen auf der zugrundeliegenden Kartenplattform. Der VAS-Container ist vollständig durch sich selbst definiert und allein funktionsfähig. Er kann ohne die in der Regel auf der gleichen Karte vorhandene Zahlungsfunktion betrieben werden. Insbesondere wird für den VAS- Container eine unabhängige Sicherheitsarchitektur definiert, so daß VAS- Applikationen eigenständige Sicherheitsfunktionen verwenden können.
Teil der Value Added Services sind Transaktionen durch den Kunden, die an Terminals der VAS-Provider durchgeführt werden. Der VAS-Provider hat ein Interesse, diese Transaktionen zu verfolgen, sei es zum Zweck der Systemüberwachung oder sei es zur Sammlung von statistischen und anderen Daten. Zur Optimierung und Vereinheitlichung der Datenstrukturen in der Karte wird von der Verwendung applikationsspezifischer Identifikationen abgeraten und die Nutzung einer systemweit eindeutigen VAS-Container ID empfohlen. Diese Nummer kann vom VAS-Provider zur Realisierung der o.g. Funktionen benutzt werden, und sie befreit ihn von der Bürde, eigene Nummernkreise zu verwalten.
Die Sicherheitsarchitektur des VAS-Containers verwendet diese systemweit eindeutige ID zur Ableitung kartenspezifischer Schlüssel. Die Verwendung der kartenspezifischen Nummer wäre im Prinzip möglich, wird aber vorzugsweise nicht verwendet, da, falls der VAS-Container auf unterschiedlichen Plattformen implementiert wird, diese unter Umständen kollidierende Nummernkreise verwenden.
Die VAS-Container ID wird vom System Operator vergeben und durch den Kartenissuer bei der Erzeugung des VAS-Containers eingebracht. Sie wird mit dem Löschen des VAS-Containers vernichtet und damit aus dem System entfernt. Ein - 2.2-
VAS-Container gilt als gelöscht, wenn er keine VAS-Applikationen enthält und die
VAS-Container ID entfernt ist.
Bei einer Gesamtübertragung des VAS-Containers von einer alten in eine neue Karte wird die VAS-Container ID zusammen mit den VAS-Applikationen transferiert. Dieser Transfer entspricht einem Verschieben des VAS-Containers aus der alten in die neue Karte. Die alte Karte enthält nach diesem Vorgang keinen VAS-Container mehr. Der in der neuen Karte vorhandene VAS-Container wird bei dieser Operation überschrieben und damit gelöscht. Da die VAS-Container ID von der alten auf die neue Karte übertragen wird, ist in den Hintergrundsystemen der VAS-Provider keine Umwandlung der Bezugsnummem erforderlich.
Einzelne VAS-Applikationen können nur unter der Kontrolle des jeweiligen VAS- Providers zwischen zwei verschiedenen VAS-Containern verschoben werden. Bei dieser Funktion ändert sich die Zuordnung zwischen VAS-Container ID und VAS- Applikation, was u.U. im Hintergrundsystem des VAS-Providers vermerkt werden muß.
Der VAS-Container enthält keine personenbezogenen Merkmale. VAS- Applikationen können personenbezogene Daten enthalten, der Umfang sollte jedoch aus Datenschutzgründen und zur besseren Speicherausnutzung auf ein Minimum beschränkt werden. VAS-Applikationen sollen, falls erforderlich, personenbezogene Daten im Hintergrundsystem speichern und die Zuordnung zur Karte über die VAS-Container ID herstellen.
Ein wesentliches Merkmal des VAS-Containers ist die Unterstützung von Interservices. Interservices erfordern Zugriff auf gemeinsame Daten, Übertragung von Leistungsansprüchen und die Abrechnung von Leistungen zwischen verschiedenen Partnern. Der VAS-Container muß dieses ermöglichen und trotzdem die Sicherheit der Applikationen im Intraservice gewährleisten. Sogenannte Intraservice VAS-Applikationen sind Applikationen, die unter der exklusiven Kontrolle des VAS-Providers betrieben werden. Der VAS-Provider definiert die Sicherheit seiner Applikation unabhängig von einer externen Stelle. Ohne Weitergabe der Schlüssel kann keine externe Partei VAS-Daten verändern.
Zur effizienten Abwicklung von Interservices müssen die Partner auf gemeinsame Daten zugreifen können. Der gemeinsame Zugriff auf die Daten ist über abgestufte Sicherheitsmechanismen realisiert.
Die erste Stufe des gemeinsamen Zugriffs erfolgt ausschließlich über öffentliche Transferfelder. VAS-Provider können über diese Felder Daten austauschen, ohne gegenseitig die Applikationen und Schlüssel kennen zu müssen. Lediglich zum Schreiben von Daten in die Transferfelder müssen die Terminals über geeignete Schlüssel verfügen, nicht aber zum Lesen. Lesen darf jeder ohne Einschränkung. Der Datenaustausch kann in beiden Richtungen zwischen VAS-Provider und Partner erfolgen, wenn jeder über seinen Schlüssel zum Schreiben verfügt. Die Transferdaten können aus einer Intraservice VAS-Applikation des VAS-Provider erzeugt werden oder umgekehrt kann der VAS-Provider Daten aus dem Transferfeld in seine Intraservice VAS-Applikation hereinnehmen.
Die zweite Stufe ist das Entwerten von Werteinheiten, die durch VAS-Daten verkörpert werden. Ein VAS-Provider bringt Werteinheiten in die VAS-Daten mit einem speziellen Schlüssel zum Schreiben ein. Die Werteinheiten können durch Interservice Partner abgenutzt werden, die über einen Schlüssel zum Entwerten verfügen, den sie vom gesamtverantwortlichen VAS-Provider bekommen. In dieser Stufe greifen Partner mit unterschiedlichen Rechten auf nicht-öffentliche VAS- Daten zu.
Die dritte Stufe ist der direkte schreibende Zugriff auf die VAS-Daten durch alle beteiligten Interservice Partner. Diese Methode erfordert ein entsprechendes Maß an Vertrauen zwischen den Parteien, da uneingeschränkt VAS-Daten verändert werden können. - 2M - Das Transferfeld dient als Koppelglied zwischen VAS-Applikationen. Daten im
Transferfeld werden von den VAS-Applikationen im VAS-Container erzeugt. Daten können auch direkt im Transferfeld angelegt werden, wenn der Erzeuger keine eigene VAS-Applikation im VAS-Container betreibt.
Das Transferfeld steht prinzipiell allen Applikationen zur Verfügung, schreiben darf aber nur wer über eine Berechtigung (Schlüssel) dafür verfügt. Nur nach den Regeln, d.h. den Rules und Regulations R&R, dazu berechtigte Empfänger dürfen Daten aus dem Transferfeld entnehmen. Der Empfänger prüft das Vorhandensein von für ihn bestimmten Transferdaten und entnimmt sie zur Verarbeitung im eigenen System.
Um die Manipulation von Transferdaten im öffentlichen Austausch zu verhindern, bringt der Erzeuger ein Echtheitsmerkmal und der VAS-Container eine Sequenznummer ein. Mit diesen Elementen wird die Einmaligkeit einer Transfernachricht sichergestellt und der Ursprung der Daten nachgewiesen.
Bei Bedarf wird der Empfänger der Transferdaten vom Erzeuger mit der Möglichkeit ausgerüstet, eine Echtheitsprüfung durchzuführen. Wird dies nicht gewünscht, kann die Akzeptanz der Daten auch nach Treu und Glauben erfolgen; das Echtheitsmerkmal wird dann u.U. erst bei einer Abrechnung im Hintergrundsystem des erzeugenden VAS-Provider geprüft.
Die Daten können aus dem Transferfeld nur einmalig mit Erhalt eines Echtheitsmerkmals entnommen werden. Bei der Entnahme werden die Daten markiert und verbleiben (als Kopie) im Transferfeld. Damit kann auch nach der Entnahme der Daten für einen bestimmten Zeitraum der Transfervorgang nachgewiesen werden.
Daten im Transferfeld tragen ein Verfallsdatum. Verfallene Daten können bei Bedarf von beliebigen Applikationen überschrieben werden. Die Daten im - z≤-
Transferfeld können bei der Entnahme markiert werden, so daß sie zum sofortigen Überschreiben freigegeben sind. Sollte sich der Transferspeicher dennoch vollständig füllen, bevor ein Transferdatensatz verfällt, so muß der Karteninhaber am Serviceterminal nicht mehr benötigte Einträge löschen.
Für die Modellierung von VAS-Applikationen werden 3 Operationen definiert. Diese Operationen wirken auf die VAS-Daten. Laden und Löschen von Applikationen sind Funktionen des VAS-Containers und werden in den folgenden Absätzen nicht betrachtet.
Erwerben Allgemein das Erwerben eines Leistungsanspruchs und die Ablage eines Nachweises in den VAS-Daten einer VAS-Applikation.
Entwerten Allgemein das Einlösen des Anspruchs ohne, mit vollständigem oder mit teilweisem Verbrauch von VAS-Daten einer Applikation. Der
Vorgang erzeugt eine elektronische Quittung, die im Transferfeld abgelegt wird. Diese Quittung trägt ein sinnvolles Verfallsdatum, zu dem sie aus dem Transferspeicher gelöscht werden kann.
Entnehmen Allgemein die Entnahme der elektronischen Quittung aus einem Transferfeld zur weiteren Verarbeitung (z.B. Hintergrundsystem). Eine Kopie der Quittung verbleibt und dient als Nachweis des „Entwertens".
„Erwerben" von VAS-Daten kann nur durch den jeweiligen VAS-Provider erfolgen. „Entwerten" von VAS-Daten kann nur durch den VAS-Provider erfolgen, der sie mit „Erwerben" erzeugte oder durch einen Interservice Partner, den der VAS-Provider dazu ermächtigt. „Entnehmen" kann auch durch jeden anderen VAS-Provider erfolgen. Bei einem Interservice ohne gleichberechtigten Zugriff auf die VAS-Daten löst der Partner den Zustandsübergang „Entnehmen" aus. Die so gewonnene elektronische Quittung kann dann über den System Operator und das Hintergrundsystem des VAS-Provider abgerechnet werden. „Erwerben" und „Entwerten" kann in einem Schritt erfolgen.
VAS-Applikationen mit gemeinsamen Merkmalen lassen sich in Klassen unterteilen. Diese Klassen bilden die Basis für Datenstrukturen im VAS-Container. Der VAS-Provider wählt bei der Implementation seiner Anwendung eine Applikationsklasse aus.
Es werden dabei folgende Applikationsklassen definiert:
• Punktespeicher
• Ticket
• Ausweis
• Gutschein • Datenspeicher
Punktespeicher bezeichnet eine Applikationsklasse, in der ein Konto von Punktwerten verwaltet wird. Auf das Punktekonto können Werte aufgebucht und abgezogen werden. Das Aufbuchen von Werten erfolgt durch den VAS-Provider, indem der Speicher mit dem neuen Kontostand beschrieben wird. Das Abbuchen von Werten erfolgt durch die „Entwerten"-Operation, wobei als Beleg eine elektronische Quittung im Transferspeicher abgelegt wird. Der Zugriff auf die beiden Funktionen ist durch zwei unterschiedliche Zugriffsschlüssel realisiert.
Ticket bezeichnet eine Applikationsklasse, in der ein Wertfeld existiert, welches einmalig oder mehrmalig entwertet und damit verbraucht wird. Das Aufbuchen von Werten in der Applikationsklasse Ticket erfolgt einmalig.
Ausweis bezeichnet eine Applikationsklasse, bei der die VAS-Daten den Nachweis einer Berechtigung beinhalten. Der Nachweis wird in der Regel nicht durch
Nutzung verbraucht; er wird allerdings nach einem definierten Kriterium, z.B. nach zeitlichem Verfall, ungültig. Je nach Ausprägung der Applikation wird die Echtheit des Ausweises (z.B. Anwohnerparkschein) oder die Vorlage eines Ausweises dokumentiert (z.B. Sammeltaxifahrt mit Monatsfahrschein: Erzeugen einer elektronischen Quittung durch die Karte. Die Quittung wird vom Taxiunternehmen beim ÖPNV eingereicht und anteilig verrechnet). Optional kann die Nutzung des Ausweises durch elektronische Quittungen im Transferspeicher der Karte dokumentiert werden.
Gutschein bezeichnet eine Applikationsklasse, bei der Leistungsansprüche (in der Regel kurzfristig) in der Karte zwischengespeichert werden. Diese elektronischen Gutscheine werden ausschließlich im Transferspeicher des VAS-Containers gespeichert. Die den Gutschein verwertende Applikation ist in der Regel eine andere als die erzeugende Anwendung. Die Entnahme des Gutscheins aus dem Transferspeicher ist nur einmalig möglich und wird durch die Karte dokumentiert. Ein vom VAS-Container erzeugtes Echtheitsmerkmal kann bei der Abrechnung im Hintergrundsystem benutzt werden.
Datenspeicher bezeichnet eine Applikationsklasse, bei der ein VAS-Provider Daten im VAS-Container speichert, die für den Kunden einen zusätzlichen Service bieten (z.B. Letztes Menü in Fast-Food Restaurant, Letzte Lottozahlen, Service Präferenzen, Vorschlagslisten). Die Daten sind nur zur Information und stellen keinen Leistungsanspruch gegen den VAS-Provider dar. Der Zugriff auf die Daten wird vom VAS-Provider gesteuert.
Jede Applikationsklasse zeichnet sich durch einen typischen Nutzungszyklus aus. Die folgende Tabelle zeigt, in welcher Frequenz die drei oben definierten Operationen auf die VAS-Daten der Applikationsklasse angewendet werden (Zur Beachtung: „Erwerben" bedeutet nicht „Applikation laden" und „Entnehmen" bedeutet nicht „Applikation löschen"). - 2 ^ —
PunkteTicket Ausweis Gutschein Datenspeicher speicher
Erwerben Mehrfach Einfach Einfach Einfach Mehrfach ***
Entwerten Mehrfach Mehrfach Mehrfach Einfach Nie
Entnehmen Mehrfach Mehrfach Mehrfach Einfach Nie
Tabelle 1 - Nutzungszyklus
*** In der Applikationsklasse „Datenspeicher" wird nicht ein Anspruch erworben, sondern die Applikation trägt lediglich Daten in die Applikation ein.
Fig. 4 veranschaulicht die oben aufgeführten Applikationsklassen und Operationen durch ein Transaktionsmodell.
Im folgenden soll auf die Sicherheitsarchitektur der erfindungsgemäßen Chipkarte näher eingegangen werden. Zur Gewährleistung der Sicherheit werden die folgenden Schlüssel definiert:
Figure imgf000030_0001
Tabelle 2 - Schlüsselübersicht - 23 -
Die Sicherheitsarchitektur basiert auf dem Lebenszyklus von VAS-Container bzw. VAS-Applikationen und ist nach der Verantwortlichkeit der beteiligten Instanzen geschichtet. Eine erläuterende schematische Darstellung ist in Fig. 5 gezeigt.
Nachfolgend einige Erläuterungen zur Struktur des VAS-Containers sowie der darauf aufgebrachten Applikationen.
Der VAS-Container sowie VAS-spezifische Ergänzungskommandos werden entweder vom Issuer zusammen mit anderen Nicht-VAS-Applikationen auf die Karte gebracht oder spätestens an einem Serviceterminal durch einen autorisierten VAS-Provider auf einer bestehenden Kartenplattform integriert.
Für die zweite Möglichkeit kann der folgende Mechanismus Verwendung finden: Der System Operator verabredet mit dem Issuer einen temporären Schlüssel Kso *. Der Issuer öffnet die Karte mit seinem nur ihm bekannten Schlüssel, legt die Dateien des VAS-Container an und schreibt insbesondere den Kso * in das DF_VAS. Der System Operator kann dann zu einem späteren Zeitpunkt (z.B. die Karte kommt zum ersten Mal mit einem Serviceterminal in Berührung) den Schlüssel Kso * durch seinen eigenen Schlüssel Kso ersetzen, den dann nur er alleine kennt. Der System Operator kann nun weitere Daten, wie z.B. den KGKDEC, selbst eintragen oder im Falle einer Plattform mit dynamischer Speicherverwaltung Dateien für VAS-Applikationen selbst erzeugen bzw. löschen. Damit ist sichergestellt, daß der Issuer nach der ersten Benutzung einer VAS-Karte keinen Zugriff mehr auf den VAS-Container hat und der System Operator lediglich Zugriff auf den VAS-Container. Da es mit anderen Applikationen keine gemeinsamen Datenstrukturen und keinerlei Datenaustausch gibt, ist die Sicherheitsarchitektur des VAS-Containers somit unabhängig von anderen auf der Kartenplattform vorhandenen Applikationen.
In einer speziellen Ausführungsform der Erfindung soll jedoch von der ersten Möglichkeit Gebrauch gemacht werden: Der Issuer soll im Auftrag des System Operator den VAS-Container inklusive aller Schlüssel auf die VAS-Karten aufbringen.
Der VAS-Container besteht aus einer vorgegebenen Dateistruktur, vorgegebenen Zugriffsbedingungen (ACs) und einigen globalen Daten. Die globalen Daten enthalten u.a. den Schlüssel Kso zum Laden bzw. Löschen von VAS-Applikationen. Über diesen Schlüssel, den nur der System Operator kennt, wird sichergestellt, daß nur zugelassene VAS-Applikationen geladen werden können. Die Karte verlangt dazu eine externe Authentifizierung des System Operators mit Kso.
Wenn ein Karteninhaber an einem Serviceterminal eine VAS-Applikation laden möchte, beauftragt der zuständige VAS-Provider den System Operator damit, dies für ihn zu tun. Beim Laden der VAS-Applikation in den VAS-Container übergibt der VAS-Provider dem System Operator die Schlüssel KLVASP und KRVASP, die dieser mit in die Applikation einträgt. Durch den Schlüssel KLVASP kann der VAS-Provider Daten der Applikation vor schreibendem Zugriff und zusätzlich interne Daten vor lesendem Zugriff schützen. Dazu verlangt die Karte eine externe Authentifizierung des VAS-Provider basierend auf KLVASP; d.h. die Karte prüft aktiv die Echtheit des Terminals. Nach erfolgreicher Ausführung dieser Funktion wird einem Terminal der schreibende Zugriff auf eine VAS-Applikation und der lesende Zugriff auf interne VAS-Daten der Applikation erlaubt. Eine interne Authentifizierung, d.h. die Prüfung der VAS-Applikation (und damit der Karte) auf Echtheit durch das Händlerterminal, kann optional erfolgen. Bei der Nutzung der VAS-Applikation durch den Karteninhaber können an beliebigen Terminals, die über den Schlüssel KLVASP verfügen, diese internen VAS-Daten in die Applikation geschrieben bzw. verändert werden. Die Funktion „Erwerben" stützt sich deshalb auf einen UPDATE RECORD Befehl, dem eine externe Authentifizierung mit dem Schlüssel KLVASP vorausgehen muß.
Der lesende Zugriff auf alle nicht internen Daten der VAS-Applikation ist nur erlaubt, wenn eine vorherige externe Authentifizierung durch KRVASP oder durch Kso oder durch die korrekte Eingabe einer PIN oder eines Paßwortes durch den System Operator erfolgt. Der PIN-/Paßwort-geschützte Zugriff wird vorgesehen, um Daten für den Karteninhaber an Terminals oder am Wallet einsehbar zu machen. Der Karteninhaber hat an einem Serviceterminal die Wahl, für alle Applikationen gleichzeitig einen PIN-/Paßwort-Schutz für das Lesen der Wert- bzw. Statusdaten zu aktivieren bzw. zu deaktivieren.
Zu den globalen Daten des VAS-Container gehört ein Schlüssel KS|G VASC zum Signieren von entnommenen Daten aus dem Transferfeld. Anhand der Signatur kann die Unversehrtheit dieser Transaktionsdaten nachgeprüft werden, wenn sie manipulationsgesichert zwischen Interservice Partnern zur gegenseitigen Verrechnung übertragen werden müssen. Zusätzlich zu einer optional durch die Interservice Partner eingebrachten Signatur wird für Datensätze, die die Karte mit der Operation „Entnehmen" ausgibt, eine Signatur basierend auf KS|G VASC uncl einem vom VAS-Container verwalteten Transaktionszähler hinzugefügt. Da zwar Lesen des Transferfeldes jedem erlaubt ist, jedoch die Signatur der Karte mit KSIG VASC nur beim Aufruf der Operation „Entnehmen" erzeugt wird (und dies kann nur einmalig geschehen), wird die unzulässige doppelte Abrechnung von Gutscheinen erkannt. Jeder Interservice Partner kann sich vom System Operator die Echtheit und Einmaligkeit eines entnommenen Gutscheins bestätigen lassen. Außerdem kann vom System Operator durch Prüfung der Signatur die Echtheit des VAS-Containers nachgewiesen werden.
Sollte eine Kartenplattform asymmetrische Schlüsselverfahren unterstützen, kann als KS|G VASC auch ein privater (geheimer) Schlüssel innerhalb der Karte zum Signieren herangezogen oder ein solcher Schlüssel aus einem privaten Key Generating Key abgeleitet werden. Die VAS-Provider könnten in diesem Fall öffentliche (nicht geheime) Schlüssel zur eigenen Prüfung der Signatur heranziehen, ohne den System Operator konsultieren zu müssen.
Zu den Daten des VAS-Container gehört ein globaler Key Generating Key KGKDEC, der für alle Terminals aller VAS-Provider zur Berechtigungsprüfung der Operation „Entwerten" den Zugriffsschlüssel KDEC erzeugen kann (mehr zur - 31- Schlüsselableitung und Prüfung folgt später). An das Entwerten von geldwerten
Daten werden nicht die gleichen Sicherheitsmaßstäbe wie an das Laden bzw.
Erwerben eines Anspruchs gestellt. Es genügt hier, anstelle eines applikationseigenen Schlüssels einen globalen Schlüssel zu verwenden. Dieser globale Schlüssel wird durch Ableitung zunächst in einen Applikationsschlüssel überführt und anschließend durch erneutes Ableiten zum Terminalschlüssel. Dem
VAS-Provider wird nur die applikationsspezifische Ableitung des globalen
Schlüssels zur Erstellung eigener Terminalschlüssel übermittelt. Dies wird nachfolgend kurz geschildert:
Wir bezeichnen mit mac(k,d) die Berechnung eines Message Authentication Code für eine Nachricht d und einen DES-Schlüssel k mittels DES. Falls die Nachricht nicht länger als 8 Bytes ist, entspricht dies der Verschlüsselung selbst (ICV=0 vorausgesetzt). Wir bezeichnen mit macp(k,d) die Berechnung von mac(k, d) mit anschließender Angleichung der Paritätsbits. Das Ergebnis k' = macp(k.d) ist wieder ein gültiger DES-Schlüssel.
Die Berechnung des applikationsspezifischen Terminalschlüssels geschieht dann wie folgt:
1. Jede Karte speichert einen Schlüssel
KGKDEC, der für alle Karten gleich ist und der das Geheimnis des System Operators ist. Der System Operator veranlaßt, daß dieser Schlüssel in die Karte personalisiert wird.
Aus diesem Schlüssel können sämtliche VAS-Applikations- und Terminalschlüssel abgeleitet werden.
2. Ein VAS-Provider möchte eine VAS-Applikation A mit AIDA=RIDVAS.PIXA einführen. Nun berechnet der System Operator aus dem Schlüssel KGKDEC und der PIX den applikationsspezifischen Schlüssel KGKDECtPIX = macp(KGKDEC, PIXA) und übergibt diesen Schlüssel dem VAS-Provider.
3. Dieser VAS-Provider leitet aus KGKDEC PIX für alle Terminals, die das TRANSFER-Kommando auf die VAS-Applikation A anwenden sollen, mit Hilfe ihrer Terminal ID ihre spezifischen Schlüssel ab:
KDEC = macp(KGrCD£C P/x, Terminal ID) = macp(macp( G D£C, PIXA), Terminal ID)
Der VAS-Provider speichert diese Schlüssel in seinen Terminals. Sofern der
VAS-Provider nicht selbst die Terminals betreibt, generiert er die Schlüssel und verteilt sie an die Betreiber der Terminals.
4. Die VAS-Karte führt das TRANSFER Kommando nur durch, wenn das Kommando ein vom Terminal erzeugtes Kryptogramm C enthält, das über bestimmte Daten data der Nachricht im Transferspeicher gebildet wird. Die Karte selbst kennt KGKDEC und bekommt von einem Terminal neben den Nutzdaten data und dem Kryptogramm C die Terminal ID sowie die PIX geschickt (bzw. die Karte kennt die PIX selbst, siehe hierzu auch die Beschreibung des Kommandos TRANSFER). Nun kann die Karte das Kryptogramm C über die Nutzdaten selbst berechnen: mac(macp(macp(KG DEC,PIX), Terminal ID),data) =
= mac(macp( GKDec P/ , Terminal lD),data) =
= mac(r 0EC,data) = = C
Die Karte vergleicht nun das selbst berechnete Kryptogramm C mit dem vom Terminal berechneten Kryptogramm C. Sind sie unterschiedlich, erfolgt ein Abbruch der Transaktion mit einer Fehlermeldung. Im Falle der Übereinstimmung wird die VAS-Karte das TRANSFER-Kommando ausführen. Die unterschiedlichen Sicherheitsmaßstäbe werden den unterschiedlichen
Bauweisen von Serviceterminals bzw. Händlerterminals (zum Laden bzw.
Erwerben) und einfachen Händlerterminals (zum Entwerten) gerecht. Ein Terminal muß sich zur Ausführung der „Entwerten" Operation gegenüber der Karte durch Kenntnis eines Schlüssels KDEC authentisieren. Bei Kompromittierung des Schlüssels KDEC kann der Angreifer lediglich die Funktionen dieses einen Terminals durchführen. Dieser Vorgang wird jedoch in der Karte protokolliert. Die Dokumentation enthält eine eindeutige Sequenznummer, die Entwertung und die Terminal ID. Die VAS-Applikationen nutzen die Sicherheitsdienste des VAS- Containers, um den Zugriff auf VAS-Daten zu reglementieren. Die Ausführung von VAS spezifischen Funktionen wird durch die Definition von Zugriffsrechten auf berechtigte Parteien beschränkt.
Im allgemeinen muß es für jede VAS-Applikation öffentlich zugängliche Datenbereiche (z.B. zum Auslesen von Werten mit einem Wallet) und private Datenbereiche des verantwortlichen VAS-Provider geben, die er vor dem Zugriff durch andere schützen kann (z.B. interne Verwaltungsdaten).
Da Karten nach ISO 7816-4 für einzelne Records von Elementary Files (EF) keinen differenzierten Zugriffsschutz bieten, müssen mehrere Dateien, die jeweils einen Record enthalten, zur Darstellung unterschiedlicher Sichten auf eine VAS- Applikation verwendet werden.
So läßt sich für die Applikationsklassen Punktespeicher, Ticket, Ausweis und Datenspeicher differenzierter Zugriffsschutz durch die Aufteilung der VAS-Daten in vier Elementary Files realisieren, wie in Fig. 6 dargestellt.
Die vier Elementary Files enthalten folgende Daten bzw. werden folgendermaßen geschützt: - 2>S
Figure imgf000037_0001
Tabelle 3 • Übersicht Dateien
Diese Struktur von Elementary Files (EF) unterstützt die gleichen differenzierten Zugriffsrechte für alle Applikationsklassen. Indem nun gleichartige Applikationsklassen zu jeweils einer Implementierungsklasse, die Anzahl und Größe der Elementary Files festlegt, zusammengefaßt werden, läßt sich ein Speicherverschnitt durch unterschiedlichen Platzbedarf für Applikationen minimieren. Die Applikationsklassen Punktespeicher und Ticket benötigen die gleichen Resourcen EF_KEY, EFJNFO, EFJNTERNAL, EF_VALUE und werden daher zusammengefaßt zur Implementierungsklasse „DF_PT". Für die Applikationsklassen Ausweis und Datenspeicher genügen die Elementary Files EF_KEY und EFJNFO und werden daher zur Implementierungsklasse „DF_AD" zusammengefaßt. Anzahlmäßig betrachtet: Es gibt p Objekte der Implementierungsklasse DF_PT und a Objekte der Implementierungsklasse DF_AD, in die VAS-Applikationen der Applikationsklassen Punktespeicher und Ticket bzw. Ausweis und Datenspeicher geladen werden können.
Speziell für die Applikationsklasse Gutschein, die öffentliche Lesezugriffe für alle VAS-Teilnehmer zum gemeinsamen Datenaustausch enthalten soll, wird die Implementierungsklasse Transferfeld verwendet. Schreibzugriffe sind ausschließlich indirekt durch die Anwendung des TRANSFER Befehls möglich, der eine Signatur mit einem korrekten KDEC verlangt. Diese Implementierungsklasse besteht aus genau einem Eintrag im Elementary File EF_TRANSFER, das zu den globalen Daten des VAS-Container gehört. Die Objekte dieser Klasse sind Records in dieser Datei. Wir nennen diese Implementierungsklasse auch „EF_TRANSFER".
Es gibt die in Fig. 7 dargestellten Implementierungsklassen innerhalb des VAS- Container. Diese Implementierungsklassen bilden das Speichermodell des VAS- Container.
Die Bereitstellung des Speichermodells kann auf zwei Arten erfolgen. Die Wahl hängt von der Kartenplattform ab: - Feste Partitionierung des Speicherbereichs für den VAS-Container:
Für die Implementierungsklassen DF_PT und DF_AD wird vom Issuer jeweils ihre maximale Anzahl p bzw. a von Objekten festgelegt und diese vom Issuer auf die Karte mit CREATE FILE Befehlen geladen. Die Objekte notieren wir mit DF_PT, bzw. DF_AD|. VAS-Applikationen können zu einem späteren Zeitpunkt in freie, also nicht von anderen VAS-Applikationen belegte Objekte geladen werden. Zum Laden bzw. Löschen von VAS-Applikationen sind dann nur UPDATE RECORD Befehle notwendig.
Der Issuer legt also die Anzahl von möglichen Objekten der beiden Implementierungsklassen nach seinen eigenen Bedürfnissen fest; dies kann eventuell nicht mit dem tatsächlichen VAS-Nutzungsverhalten des Karteninhabers übereinstimmen. Die Aufteilung wird über den gesamten Lebenszyklus der Karte beibehalten. Eine VAS-Applikation wird in ein Objekt geladen, das von einer geeigneten Implementierungsklasse ist. So kann z.B. eine VAS-Applikation, die einen Ausweis darstellt, auch in einem Objekt der Implementierungsklasse DF_PT untergebracht werden, wenn keine Objekte der Implementierungsklasse DF_AD (mehr) zur Verfügung stehen. Die Zuweisung einer VAS-Applikation zu einem Objekt erfolgt durch den Eintrag eines Tripeis
(PIX der VAS-Applikation, FID des belegten Objektes, Klartextname der Applikation) in die globale Datei EFJDIR des VAS-Container. Das Entfernen der Applikation entspricht dem Entfernen dieses Tripeis aus EFjDIR und dem zerstörenden Lesen (durch UPDATE RECORD Befehle) des von der Applikation belegten Speichers.
Diese Variante findet Verwendung bei Kartenplattformen, die keine dynamische Erzeugung bzw. Löschung von DF/EF Strukturen unterstützen.
- Dynamisches Anlegen von Objekten der Implementierungsklasse: - £- Für jede zu ladende VAS-Applikation werden mit CREATE FILE Befehlen die für die zugrundeliegende Implementierungsklasse benötigten Dateien angelegt.
Beim Löschen der VAS-Applikation wird die von ihr belegte DF/EF vollständig aus der Karte entfernt und der Speicherplatz freigegeben. Die maximale Anzahl von Objekten von Implementierungsklassen ist hier nicht explizit vom Issuer festzulegen und hängt nur vom zur Verfügung stehenden Speicherplatz der
Karte ab.
Diese Variante erfordert eine dynamische Speicherverwaltung durch das Kartenbetriebssystem.
Im vorliegenden Ausführungsbeispiel gehen wir von der ersten Variante aus, da die zweite erhöhte Anforderungen an die zur Verfügung stehende Kartenplattform stellt. Steht eine dynamische Speicherverwaltung jedoch zur Verfügung und ist sichergestellt, daß sich durch das dynamische Anlegen von Objekten mehr Speicher sparen läßt als die Verwaltung kostet, dann kann das bestehende Konzept übernommen werden und bietet dem Karteninhaber mehr Flexibilität.
Im folgenden werden die Datenstrukturen und Kommandos vorgestellt, mit denen sich der VAS-Container und die Funktionalität der VAS-Kundenkarte gegenüber anderen Systemkomponenten realisieren lassen. Außerdem werden für typische Geschäftsfälle VAS-Operationen festgelegt, die die jeweilige Interaktion zwischen VAS-Container und Terminal beschreiben.
Für die Implementierung wird von folgenden Voraussetzungen ausgegangen:
• An einem Händlerterminal stellt jede Karte, unabhängig von der Plattform, die gleiche Daten- und Kommandoschnittstelle zur Verfügung. Die erforderlichen Kommandos sind daher in ihrer Kodierung eindeutig beschrieben.
Serviceterminals sind fähig, die Kartenplattform zu erkennen. Die Funktionalität kann daher durch spezifische Kommandos der Plattform erreicht werden. Diese - ^ - Vorgänge sind daher teilweise informell beschrieben. Wie diese Funktion bereitgestellt wird ist dem Karten hersteiler freigestellt.
In Fig. 7 werden hierzu schematisch verschiedene Implementierungsklassen des VAS-Containers dargestellt. Fig. 8 zeigt schematisch die Dateistruktur des VAS- Containers, Fig. 9 zeigt schematisch die Dateistruktur der Implementierungsklasse DF_PT, Fig. 10 die Dateistruktur der Implementierungsklasse DF_AD.
Der Zugriff auf die Dateien des VAS-Container wird explizit durch folgende Access Conditions (AC) eingeschränkt:
Figure imgf000041_0001
Tabelle 4 - Zugriffsbedingungen
Dabei haben die AC folgende Bedeutung:
• ALW (Always) = Der Zugriff des Kommandos auf die Datei ist immer erlaubt.
• NEV (Never) = Der Zugriff des Kommandos auf die Datei ist nie erlaubt. • Kso = Vor Zugriff muß externe Authentifizierung des System Operator mit dem Schlüssel Kso erfolgen.
• KLVASP = Vor Zugriff muß externe Authentifizierung des VAS-Provider mit dem Schlüssel KLVASP erfolgen. • KRVASP = Vor Zugriff muß externe Authentifizierung eines vom VAS-Provider autorisierten Terminais mit dem Schlüssel KRVASP erfolgen.
• PIN = Vor Zugriff muß die korrekte PIN durch den Karteninhaber eingegeben werden und im Klartext mit dem Kommando VERIFY an die Karte geschickt werden. • PIN oder KRVASP oder Ks0 = Vor Zugriff muß entweder die korrekte PIN durch den Karteninhaber eingegeben werden, oder es erfolgt eine externe Authentifizierung durch den VAS-Provider mit KRVASP oder durch den System Operator mit Kso.
Dabei ist anzumerken, daß die Oder-Verknüpfung von Zugriffsrechten, wie oben beschrieben, in Kartenbetriebssystemen in der Regel nicht vorgesehen ist. Eventuell bedeutet dies besonderen Implementierungsaufwand. (Alternative: spezielles READ Kommando mit implizit festgelegtem Sicherheitsattribut).
Datenfelder innerhalb der Records von Elementary Files werden nach folgenden Formaten unterschieden: ASCII, Binär, BCD, Datum, Formatstring.
Datenelemente vom Typ „Formatstring" enthalten VAS-Daten in gepackter Darstellung, die dem Karteninhaber am Terminal angezeigt werden können.
Zur optimalen Speicherausnutzung werden Klartext und binäre Daten gemischt und über Formatiermakros darstellbar gemacht.
Sämtliche Elementary Files (EF) des VAS-Container sind nach ISO 7816-4 definiert als lineare formatierte EF Dateien mit Records konstanter Länge (linear fixed record files). -m-
Das Elementary File EF_ID des DF_VAS besteht aus einem Record, der die VAS- Container ID enthält.
Das Elementary File EF_DIR des DFJVAS besteht aus nrD,R Records. Für jede in den VAS-Container geladene VAS-Applikation wird in einem Record des EFJDIR ihr Proprietary Identifier Extension (PIX) und ihr physikalischer Speicherplatz (FID des DF_X, in den die Applikation geladen wurde) festgehalten. Die PIX identifiziert z.B. als Kennziffer die Applikation und den Service-Provider, dem die Applikation zugordnet ist.
Die Einträge im EF_DIR werden am Service Terminal des System Operators dynamisch angelegt. Records ohne Eintrag werden mit einem leeren TLV Objekt '61' angelegt.
Beim Laden einer VAS-Applikation wird zunächst ein freier Speicherbereich der für sie passenden Implementierungsklasse gesucht, bestimmte VAS-Daten dort eingetragen und schließlich im EFJDIR ein neuer Record erzeugt.
Beim Löschen einer Applikation muß in EF_DIR entsprechend ein leeres TLV Objekt geschrieben werden.
Das Elementary File EFJVERSION des DFJVAS besteht aus einem Record, der eine Versionsnummer des VAS-Container enthält.
Die Versionsnummer kann von Terminals dazu benutzt werden, verschiedene VAS-Container-Varianten und/oder verschiedene Software-Versionen zu unterscheiden.
Das Elementary File EFJ3EQ des DFJVAS besteht aus einem Record, der die Nummer des nächsten Transferfeldeintrags enthält.
Die Sequenznummer wird vom Ergänzungskommando TRANSFER ausgelesen. Dieses Kommando erzeugt daraufhin im Transferfeld EFJTRANSFER einen - 41- Record, in den u.a. die Sequenznummer aus EFJ3EQ übertragen wird. Zusammen mit dem Kommando TAKE, das sicherstellt, daß jeder Record aus dem
Transferfeld nur einmal entnommen wird und diese Entnahme per Signatur über die Sequenznummer dokumentiert, kann die einmalige Entnahme von (Original-) Gutscheinen bzw. Quittungen garantiert werden.
Im folgenden soll nun genauer auf den Transferspeicher eingegangen werden.
Der Transferspeicher wird innerhalb des VAS-Containers angelegt und umfaßt nrEF TRANSFER Records. Einträge in den Records dieses Files enthalten Transferdaten, die vom TRANSFER Kommando erzeugt werden. Über den Transferspeicher wird sowohl der Datenaustausch zwischen VAS-Applikationen als auch die Speicherung von VAS-Daten der Klasse Gutschein abgewickelt.
Der Transferspeicher kann ohne Beschränkung gelesen werden, der schreibende Zugriff ist jedoch nur durch die VAS-spezifischen Kommandos TRANSFER und TAKE möglich.
Die Belegung der Datenfelder durch den TRANSFER Befehl geschieht durch einen „Last-recently-used" Algorithmus in der Karte. Der älteste Record in der Datei kann durch Suchen des kleinsten Wertes in den ersten 2 Bytes des Records ermittelt werden.
Datenfelder können mit dem Befehl „TAKE" im Transferspeicher als entnommen und/oder entfernt markiert werden. In jedem Fall erfolgt das Löschen von Daten im Transferspeicher durch Überschreiben mit neuen Daten.
Jeder Record im Transferspeicher enthält beispielsweise ein Verfallsdatum, die Terminal-ID, die PIX, die Sequenznummer und eventuell weitere Daten.
Jedes Elementary File EFJNFO innerhalb von Verzeichnissen DF_X (mit X = PT-,, ..., PTP, AD.,, ..., ADa) besteht aus einem Record, der das Verfallsdatum sowie - H S - allgemeine VAS-Daten einer VAS-Applikation enthält. Beispielsweise kann die Art eines Tickets (Einzel- oder Streifenfahrschein) oder der Einsteigeort hier angegeben werden. EFJNFO muß jedoch zumindest einen Klartextnamen der
Applikation enthalten, der für die Operation Ansehen VAS-Applikationen auslesbar ist. Sensible Daten muß der VAS-Provider durch geeignete externe
Verschlüsselungsalgorithmen schützen.
Dieses EF ist lesbar, wenn eine externe Authentifizierung mit Kso oder KRVASP erfolgt oder der Karteninhaber im Falle eines aktivierten PIN-Schutzes eine korrekte PIN eingibt.
Jedes Elementary File EFJNTERNAL innerhalb von Verzeichnissen DF_X (mit X =
PT1 f ..., PTP, AD., ADa) besteht aus einem Record, der interne VAS-Daten des
VAS-Provider über seine geladene VAS-Applikation enthalten kann. Weder Karteninhaber noch ein anderer VAS-Provider können diese internen Daten lesen.
Jedes Elementary File EFJVALUE innerhalb von Verzeichnissen DF_X (mit X = PT.,, ..., PTP, AD.,, ..., ADa) besteht aus einem Record, der ein ganzzahliges Wertfeld der VAS-Daten enthalten kann. Dieses EF ist lesbar, wenn eine externe Authentifizierung mit Kso oder KRVASP erfolgt oder der Karteninhaber im Falle eines aktivierten PIN-Schutzes eine korrekte PIN bzw. ein korrektes Paßwort eingibt.
Die folgenden Schlüsselfelder werden vom VAS-Container oder von der VAS- Applikation benutzt. Im folgenden wird von einer reinen DES-Verschlüsselung ausgegangen. D.h. sämtliche Schlüssel des VAS-Containers sind DES-Schlüssel und sind in 8 byte codiert (einschließlich Paritätsbits).
Innerhalb des VAS-Containers und innerhalb der VAS-Applikationen können folgende Schlüssel durch ihren KID (Key Identifier) referenziert werden: -U 4-
Figure imgf000046_0001
Tabelle 5 - Schlüssel VAS-Container
Jeder Schlüssel ist mit einem Fehlbedienungszähler verknüpft. Dieser registriert fehlgeschlagene Authentifizierungsversuche mit diesem Schlüssel und blockiert eine weitere Nutzung, wenn ein Limit für diesen Zähler eingetragen und erreicht ist.
Innerhalb der VAS-Applikation können folgende Schlüssel durch ihren KID referenziert werden.
Figure imgf000046_0002
Tabelle 6 - Schlüssel VAS-Applikation
Jeder Schlüssel ist mit einem Fehlbedienungszähler verknüpft. Dieser registriert fehlgeschlagene Authentifizierungsversuche mit diesem Schlüssel und blockiert eine weitere Nutzung, wenn ein Limit für diesen Zähler eingetragen und erreicht ist.
Der VAS-Container enthält eine persönliche Identifikationsnummer oder Paßwort (PIN). Dies wird vom VERIFY Kommando zur Identifikation des Karteninhabers benutzt. Die PIN ist verknüpft mit einem Fehlbedienungszähler, der jede Falscheingabe registriert und bei Erreichen eines Limits den PIN-Vergleich sperrt. Diese Sperre kann durch den System Operator mit geeigneten Administrationskommandos zurückgesetzt werden. Der Fehlbedienungszähler wird bei korrekt eingegebener PIN zurückgesetzt. -M S"-
Es gibt folgende Parameter für den VAS-Container, die vom Kartenherausgeber gemäß dem zur Verfügung stehenden Platz auf einer Kartenplattform und seinen individuellen Wünschen gewählt werden können:
• p Maximale Zahl von Objekten der Implementierungsklasse DF_PT = maximale Zahl von VAS-Applikationen der Applikationsklassen
Punktespeicher und Ticket, die gleichzeitig in einen VAS-Container geladen werden können;
• a Maximale Zahl von Objekten der Implementierungsklasse DF_AD = maximale Zahl von VAS-Applikationen der Applikationsklassen Ausweis und
Datenspeicher, die gleichzeitig in einen VAS-Container geladen werden können;
• nrD!R Maximale Gesamtzahl von Objekten: nrD!R = p + a Die Anzahl von Records in EFJDIR ist nrD,R
• nrEF TRANSFER Anzahl von Records des EF_TRANSFER
Der Speicherbedarf für die Größen der beschriebenen Elementary Files ist:
Byte
Globale Daten des VAS-Containers: EFJD 4
EF_DIR 9 * (p+a)
EFJVERSION 1
Figure imgf000047_0001
Globale Keys, Pin 64+2
Transferfeld: EFJTRANSFER 48 * nrEF_TRANSFER
Proprietäre Daten der VAS-Provider: EF_KEY (p+a) * 32
EFJNFO (p+a) * 62
EFJNTERNAL p * 10 EFJ/ALUE p * 3 Wählen wir z.B. für die Parameter p, a und nrEF_TRANSFER folgende Werte, dann ergibt sich folgender Mindestspeicherbedarf für den VAS-Container (ohne Speicherbedarf für Ergänzungskommandos):
Parameter Speicherbedarf p = 8, a = 3, nrEF TRANSFER = 15 2030 Byte p = 10, a = 5, nrEF TRANSFER = 20 2758 Byte
Der Maximalspeicherbedarf ist wahrscheinlich um ca. 10% höher als der Mindestspeicherbedarf.
Im folgenden wird nun genauer auf die Kommandos der erfindungsgemäßen Chipkarte eingegangen.
Das READ RECORD Kommando wird zum Auslesen von Daten aus linearen Elementary Files benutzt. Die Karte liefert in der Rückantwort den Inhalt des Records. Das EF wird durch den Short File Identifier (SFI) referenziert.
Der Status Code '9000' signalisiert eine erfolgreiche Durchführung des Kommandos; jeder andere Code wird als Fehler bewertet.
Der UPDATE RECORD Befehl wird benutzt, um Daten in die Records eines linearen EF einzubringen. Die Kommandonachricht enthält die Referenz auf das EF, den Record und die Daten.
Die Antwort der Karte enthält den Statuscode. Der Statuscode '9000' signalisiert den erfolgreichen Abschluß der Kommandos. Andere Statuscodes zeigen den Fehlerfall an.
Das GET CHALLENGE Kommando fordert von der Karte eine Zufallszahl an. Die Zufallszahl wird im Zusammenhang mit der dynamischen Authentifizierung im EXTERNAL AUTHENTICATE verwendet. Die Antwortnachricht der Karte enthält eine 8 bytes lange Zufallszahl und den Statuscode. Der Statuscode '9000' zeigt die erfolgreiche Ausführung des Kommandos an. Andere Statuscodes zeigen den Fehlerfall an.
Das Kommando EXTERNAL AUTHENTICATE erlaubt die Authentifizierung eines Terminals gegenüber der Karte. EXTERNAL AUTHENTICATE wird im Rahmen von VAS-Applikationen zur Authentifizierung des System Operators und des VAS- Providers benutzt. EXTERNAL AUTHENTICATE überträgt ein Kryptogramm in die Karte, das zuvor vom Terminal durch Verschlüsseln einer Zufallszahl erzeugt werden muß. Die Karte vergleicht das Kryptogramm mit einem Referenzwert, den sie selbst nach dem gleichen Verfahren berechnet hat. Sind beide Werte gleich, so vermerkt die Karte intern, daß die Zugriffsbedingung Authentifizierung für diesen Schlüssel erfolgt ist. Sollte der Vergleich negativ ausfallen, so gibt die Karte den Status „Nicht autorisiert" zurück und dekrementiert einen internen Fehlbedienungszähler. Erreicht dieser Zähler den Wert 0, so wird jede weitere Ausführung des EXTERNAL AUTHENTICATE mit dem Status „Authentifizierung gesperrt" abgewiesen.
Die Antwortnachricht der Karte enthält den Statuscode. Die erfolgreiche Durchführung des Kommandos und die Authentifizierung der Terminals gegenüber der Karte wird durch den Statuscode '9000' angezeigt. Andere Statuscodes zeigen den Fehlerfall an.
Das Kommando INTERNAL AUTHENTICATE wird benutzt, um die Echtheit des VAS-Containers durch ein Terminal prüfen zu können. Die Karte berechnet dazu ein Kryptogramm über Referenzdaten vom Terminal. Das Terminal bildet seinerseits das Kryptogramm und vergleicht es mit dem Wert von der Karte. Bei Gleichheit kann das Terminal die Echtheit des VAS-Containers annehmen.
Die Antwort der Karte enthält das Kryptogramm und den Statuscode für die Ausführung des Kommandos. Die erfolgreiche Durchführung des Kommandos wird durch den Statuscode '9000' angezeugt. Andere Statuscodes zeigen den Fehlerfall an.
Das VERIFY Kommando wird zur Verifikation der Karteninhaber PIN benutzt. Das Kommando überträgt die PIN Daten unverschlüsselt an die Karte, wo ein Vergleich mit einem gespeicherten Referenzwert durchgeführt wird. Sind eingegebener und gespeicherter Wert identisch, so wird die Zugriffsbedingung „PIN" als erfüllt betrachtet.
Die Antwortnachricht der Karte enthält den Statuscode. Der Statuscode '9000' zeigt die erfolgreiche Durchführung des Kommandos an. Andere Statuscodes zeigen den Fehlerfall an.
Das TRANSFER Kommando erzeugt einen Eintrag im Transferspeicher. Drei Arbeitsmodi sind für das Kommando definiert:
1. Erzeugen eines Eintrags im Transferfeld durch Verringern von Werten im EFJVALUE Feld der Applikation der Klasse Ticket oder Punktespeicher.
2. Erzeugen eines Eintrags im Transferfeld durch Erstellen einer Quittung in Applikationen der Klasse Ausweis.
3. Erzeugen eines Eintrags im Transferfeld durch Erstellen eines Gutscheins in Applikationen der Klasse Gutschein.
Der Arbeitsmodus wird durch die Karte automatisch ausgewählt: Wird der Befehl innerhalb eines selektierten Applikations-DF ausgeführt, so wird zunächst das Vorhandensein eines EFJ/ALUE überprüft. Bei vorhandenem EFJVALUE führt die Karte den Befehl im Modus 1 , ansonsten im Modus 2 durch. Ist innerhalb des VAS- Containers kein Applikations-DF ausgewählt, wird Modus 3 benutzt.
Das Terminal versorgt die Karte beim Aufruf des TRANSFER Kommandos mit den folgenden Daten: • Aktuelles Datum
• Verfallsdatum für den Eintrag im Transferfeld
• Identifikation für das Terminal, welches diesen Eintrag erzeugt
• Nutzdaten für das Transferfeld • PIX der VAS-Applikation (nur Modus 3)
• Anzahl abzuziehender Einheiten (nur Modus 1 )
• MAC über die o.g. Daten, die Sequenznummer und die VAS-Container Nummer.
Die Karte führt beim Aufruf des TRANSFER Kommandos die folgende Sequenz aus:
1. Suchen nach einem freien Eintrag im Transferspeicher. (Die folgende Aufzählung gibt absteigend die Priorität wieder, in welcher vorhandene Eintragungen überschrieben werden sollen: „Eintrag als entfernt markiert", „Eintrag als entnommen markiert" und „Verfallsdatum erreicht", „Verfallsdatum erreicht").
2. Anhängen der PIX an die Daten vom Terminal in den Modi 1 und 2.
3. Anhängen der Sequenznummer an die Daten aus Schritt 2.
4. Anhängen der VAS-Container ID an die Daten aus Schritt 3. 5. Ableiten des KGKDEC P,X durch Verschlüsseln der PIX unter dem KGKDEC.
6. Ableiten des KDEC durch Verschlüsseln der Terminal ID unter dem KGKDEC P,x.
7. Erzeugung des MAC über die Daten aus Schritt 4.
8. Vergleich des MAC aus Schritt 7 mit dem MAC vom Terminal. Sind die Werte unterschiedlich, bricht die Karte die Funktion ab und verringert den Fehlbedienungszähler für den KGKDEC.
9. Für Modus 1 : Prüfung des Wertfeldes EFJVALUE im Verzeichnis, in das die Applikation geladen wurde. Sind nicht genügend Einheiten in diesem Feld vorhanden, bricht die Karte die Funktion an dieser Stelle ab. Andernfalls wird das Wertfeld in der Applikation um den Betrag vermindert. 10. Zusammenstellen der Kommandonachricht. 1 1 . Inkrementieren des Inhalts von EF SEQ um 1. - SO- Die Ausgabe des Datensatzes in der Antwort ist daher nicht notwendig. Es kann weiterhin angenommen werden, daß die Nummer des Records bekannt ist.
Das Kommando TAKE stellt folgende Modi bereit:
• Entnahme mit gleichzeitigem Vermerk, daß die Daten ungültig geworden sind
• Entnahme ohne vorstehenden Vermerk. Die Daten bleiben weiterhin gültig.
Die Kommandonachricht enthält Felder mit Terminal-ID, PIX der Applikation und eine vom Terminal generierte Zufallszahl.
Die PIX im Kommando bezeichnet die entnehmende Anwendung. Sie darf verschieden sein von der PIX des Datensatzes, der entnommen wird. Sie dient ausschließlich zur Ableitung von KDEC des entnehmenden Händlerterminals.
Die Antwortnachricht der Karte enthält ein Kryptogramm C-, mit KS|G VASC UDer die Daten des in der Kommandonachricht angegebenen Records des Transferfeldes und die VAS-Container ID, ein Kryptogramm C2 mit KDEC des entnehmenden Terminals über C1 und die Zufallszahl aus der Kommandonachricht. Die Antwortnachricht enthält zusätzlich den Statuscode. Der Schlüssel KDEC wird wie vorher beschrieben abgeleitet. Mit dem Kryptogramm vermöge KDEC wird implizit ein Echtheitsnachweis durch den VAS-Container erbracht. Mit dem Kryptogramm C wird ein Echtheitsnachweis und Einmaligkeitsnachweis (da C über Sequenznummer, Entnommen-Bit des Transferfeld-Records und VAS-Container ID gebildet werden) berechnet, den der Systemoperator verifizieren kann.
Der Statuscode '9000' zeigt die erfolgreiche Durchführung des Kommandos an. Andere Statuscodes werden als Fehler interpretiert.
Es ist davon auszugehen, daß der SO eine AIDVAS gemäß ISO/IEC 7816-5 beantragt. Genauer: Er beantragt eine 5 Byte lange RIDVAS für das VAS-System.
Die AIDVAS des Verzeichnisses DFJVAS soll lauten: AIDVAS = RIDVAS.PIXDF VAS- Die Kommandonachricht enthält beispielsweise Felder mit einem Verfallsdatum, der Terminal ID, den Transaktionsdaten, ein Feld für den Betriebsmodus (enthält z.B. im Modus 3 die PIX), sowie ein Kryptogramm.
Das Kryptogramm wird unter Verwendung des Schlüssels KDEC berechnet, wobei die Daten, über die der MAC gebildet wird, beispielsweise die Transaktionsdaten und die Terminal-ID umfassen.
Die Antwortnachricht des TRANSFER Kommandos umfaßt im Erfolgsfall einen 8 Byte langes Datenfeld und den 2 Byte langen Statuscode '9000'. Antwortnachrichten mit einem von '9000' verschiedenen Statuscode werden als Fehlercode interpretiert. Das Datenfeld der Antwortnachricht enthält im fehlerfreien Fall (d.h. insbesondere war das Kryptogramm der Kommandonachricht korrekt) das mit KDEC verschlüsselte Kryptogramm der Kommandonachricht. Dadurch wird implizit (anstelle einer internen Authentifizierung mit KAUT) ein Echtheitsnachweis durch den VAS-Container erbracht.
Das Kommando TAKE dient zur Entnahme von Objekten aus der Implementierungsklasse EF_TRANSFER. Technisch bedeutet die Ausführung des Kommandos TAKE das Auslesen eines anzugebenden Records aus der Datei EFJTRANSFER, wobei der Record in der Datei so lange verbleibt, bis der Speicherplatz für neue Einträge benötigt wird, der Datensatz wird als entnommen markiert. Technisch gesehen kann jeder das Kommando TAKE nutzen, um einen Datensatz zu entnehmen, nach den R&R sollte dies jedoch nur ein VAS-Provider tun, für den der Datensatz bestimmt ist.
Für den Entnahmevorgang kann folgendes angenommen werden. Der VAS- Provider, der einen Gutschein oder eine Quittung entnehmen will, durchsucht den Transferspeicher nach einem passenden Datensatz (z.B. durch das Kommando SEEK oder durch explizites Lesen jedes Records). Der Datensatz wird in jedem Fall gelesen und eventuell inhaltlich geprüft. Für jede VAS-Applikation A wird gemäß R&R eine 3 Bytes lange PIXA vergeben, um sie innerhalb des VAS-Container eindeutig mit AIDA = RIDVAS.PIXA identifizieren zu können. Nach der Selektion des DFJVAS kann ein Verzeichnis, in dem die VAS-Applikation A enthalten ist, mit SELECT FILE < PIXA > ausgewählt werden.
Mit dem UPDATE KEY (KID, K) sei ein von der Kartenplattform abhängiges Kommando bezeichnet, mit welchem ein Schlüssel mit Key Identifier ID durch den neuen Wert K ersetzt wird.
Bevor eine VAS-Applikation aus einer der Implementierungsklassen DF_PT oder DF_AD (dies entspricht den Applikationsklassen Punktespeicher, Ticket, Ausweis oder Datenspeicher) durch den Karteninhaber an Händlerterminals genutzt werden kann, muß sie an einem Serviceterminal des zuständigen VAS-Provider in den VAS-Container geladen werden. Prinzipiell ist auch möglich, daß ein Kartenherausgeber im Auftrag eines VAS-Provider und eines SO bereits beim Aufbringen des VAS-Containers eine oder mehrere VAS-Applikationen in den VAS- Container lädt. Dieser Ladevorgang ist ein Spezialfall des hier beschriebenen.
Ablauf des Ladens einer VAS-Applikation:
1. Karteninhaber führt eine VAS-Karte in ein Serviceterminal ein.
2. Das Serviceterminal prüft, ob ein VAS-Container vorhanden ist:
• SELECT FILE < AIDVAS > (Fehlermeldung wenn VAS-Container nicht selektierbar) • READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container Nummer)
Optional wird die Gültigkeit des VAS-Containers geprüft. Dazu verlangt das
Serviceterminal eine interne Authentifizierung des VAS-Containers: • INTERNAL AUTHENTICATE < Zufallszahl, KID von KAUT >
Das Serviceterminal prüft die Antwort und bricht im Fehlerfall (mit Fehlermeldung) ab.
3. Das Serviceterminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. Eine davon lautet Laden VAS-Applikation. Diese wählt der Karteninhaber aus. Nun werden dem Karteninhaber alle VAS-Applikationen, die am Serviceterminal geladen werden können, angezeigt, und es wird auf eine Auswahl gewartet. Dazu wird die Operation Ansehen VAS-Applikationen aktiviert. Der Karteninhaber wählt eine VAS-Applikation A der
Implementierungsklasse DF_PT oder DF_AD aus.
4. Das Serviceterminal untersucht den VAS-Container mit der Operation Selektion einer VAS-Applikation, ob die ausgewählte VAS-Applikation mit PIXA bereits in der Karte geladen ist. Falls ja, wird eine Fehlermeldung ausgegeben. Falls nicht, wird geprüft, ob noch ein Objekt der für A geeigneten Implementierungsklasse im VAS-Container frei ist. Dies geschieht durch Suchen eines freien Records in EFJDIR (z.B. mit dem Kommando SEEK). Falls nichts frei ist, wird eine Fehlermeldung ausgegeben. Falls ein Record frei ist, enthält dieser eine FIDDF X eines DF_X, in das keine VAS-Applikation geladen ist.
5. Das nächste freie Objekt der für A geeigneten Implementierungsklasse wird belegt für die VAS-Applikation A. Dabei erfragt zunächst das Serviceterminal offline vom VAS-Provider (z.B. durch ein VAS-Provider-SAM) zwei Schlüssel
KLVASP und KRVASP ur|d weist sie der neuen VAS-Applikation zu:
• SELECT FILE < FIDDF X >
• GET CHALLENGE • EXTERNAL AUTHENTICATE < Ks0(Zufallszahl), KID von Kso >
• UPDATE KEY < KID von KLVASP, KLVASP > • UPDATE KEY < KID von KRVASP, KRVASP >
• GET CHALLENGE
• EXTERNAL AUTHENTICATE < KLVAsp(Zufallszahl), KID von KLVASP >
• UPDATE RECORD < SFI von EFJNFO des DF_X, Daten > • UPDATE RECORD < SFI von EFJNTERNAL des DF_X, Daten >
• Optional (Initialisierung): UPDATE RECORD < SFI von EFJ ALUE des DF_X, Daten >
6. Nach dem erfolgreichen Schreiben in die EFs wird vom Serviceterminal die Operation Eintrag VAS-Applikation < PIXA, FIDDF X > ausgeführt, die das DF_X mit dem PIXA verbindet und so SELECT FILE mittels des PIXA (nach der vorherigen Selektion mit SELECT FILE AIDVAS) ermöglicht.
Der mit dem Transferspeicher zur Verfügung gestellte Mechanismus läßt sich z.B. von VAS-Providern nutzen, die Intra- oder Interservices ohne proprietäre DF- Strukturen abwickeln möchten. Ein Karteninhaber muß dann insbesondere vor der Benutzung einer VAS-Applikation diese nicht erst an einem Serviceterminal laden. Er kann dagegen direkt am Händlerterminal sich einen Gutschein oder eine Quittung ausstellen und diese an einem anderen Terminal erstatten (durch die Operation Entnehmen) lassen oder den Gutschein bzw. die Quittung nur einfach vorweisen (durch Lesen). Das Laden einer VAS-Applikation der Implementierungsklasse EFJTRANSFER wird daher implizit durch Aufbringen von VAS-Daten realisiert bzw. auf diese Operation zurückgeführt. Hierzu wird auf die später folgende Beschreibung des Erwerbens der Implementierungsklasse EFJTRANSFER verwiesen.
Nachfolgend wird der Ablauf der Operation des Eintrags einer VAS-Applikation beschrieben.
Ist eine VAS-Applikation in den VAS-Container geladen, ist einem Terminal der physikalische Ort unbekannt, in welchem DF_X mit X = PT1 f ..., PTP, AD^ ..., ADa die VAS-Applikation bzw. ob sie überhaupt geladen ist. Aus Sicht des Kartenherstellers sind zwei mögliche Implementierungsweisen möglich, die getrennt geprüft werden sollen; dabei ist insbesondere die Konsistenz zum ZKA- Standard zu beachten.
Der erste Fall: Zugriff auf EFJDIR möglich
Folgende Voraussetzungen sind zu erfüllen:
• Es gebe standardmäßig in der Kartenplattform ein EFJDIR (z.B. unter DFJVAS), in dem AIDs den FIDs der DF_X zugeordnet sind, in denen sich VAS- Applikationen aktuell befinden.
• Dieses EFJDIR ist für jeden lesbar (AC von READ RECORD: ALW).
• Wird eine VAS-Applikation A mit PIXA vom System Operator in ein freies (unbenutztes) DF_X geladen, d.h. die vorhandenen Elementary Files dieses DF_X beschrieben (kein CREATE FILE !), dann soll durch ein UPDATE
RECORD die Datei EFJDIR um den Eintrag PIXA erweitert werden können, der auf dieses DF_X verweist mit FIDX. Die AC von UPDATE RECORD sollte daher eine externe Authentisierung mit dem Schlüssel Kso erzwingen.
• Wird der Befehl SELECT FILE < PIXA > nach der vorherigen Selektion von DFJVAS an die Karte übermittelt, muß das DF_X, in das eine VAS-Applikation A geladen ist, direkt selektierbar sein.
• Wenn eine VAS-Applikation A, die in DF_X und den darunterliegenden Elementary Files geladen ist, auf Wunsch des Karteninhabers an einem Service- Terminal gelöscht werden soll, werden die entsprechenden Dateien nicht mit DELETE FILE gelöscht, sondern die eingetragenen Daten lediglich mit Dummy-
Werten überschrieben. Danach soll aus EFJDIR der Eintrag PIXA (genauer das Paar PIXA und der Verweis auf DF_X) gelöscht werden können (z.B. durch UPDATE RECORD mit vorheriger externer Authentisierung mit dem Schlüssel
Kso)- -S - • Da die Anzahl der DF_X fest ist, ist die Anzahl der Records von EFJDIR bekannt.
Ist dieser Ansatz realisierbar, ergibt sich folgende Konsequenz:
• Ein nach Selektion von DFJVAS direkt erfolgendes Selektieren einer VAS- Applikation mit SELECT FILE PIXA ist möglich.
Der zweite Fall: Zugriff auf EFJDIR nicht möglich
Steht bei der Kartenplattform kein EFJDIR zur Verfügung oder ist kein lesender und schreibender Zugriff auf dieses EFJDIR - wie im obigen Abschnitt dargestellt - möglich, soll es unter DFJVAS eine Datei EFJ/ASDIR geben, in der vom System Operator durch explizite UPDATE RECORD Befehle (nach vorheriger externer Authentifizierung mit Kso) ein Bezug der PIXA geladener VAS-Applikationen zu ihrem physikalischem Speicherplatz in einem DF_X hergestellt wird. Das Lesen und Löschen von Records aus EFJVASDIR soll wie vorher beschrieben möglich sein.
Der Ablauf der Operation Eintrag VAS-Applikation läuft wie folgt:
Eine VAS-Applikation A mit PIXA wurde vorher in ein freies DF_X mit FIDDF X geladen. Die Nummer des Records mit FIDDF X wurde vom Serviceterminal vermerkt.
1. SELECT FILE < AID AS > (Fehlermeldung wenn VAS-Container nicht selektierbar)
2. GET CHALLENGE
3. EXTERNAL AUTHENTICATE < KS0(Zufallszahl), KID von Ks0 >
4. UPDATE RECORD < SFI von EFJDIR des DFJVAS, Nummer Record mit FIDDF x, PIXA, FIDDF X> - + -
VAS-Applikationen der Implementierungsklassen DF_PT oder DF_AD können nur an Serviceterminals (da unter Hoheit des System Operator) auf Wunsch des Karteninhabers gelöscht werden, VAS-Applikationen der Implementierungsklasse EFJTRANSFER können überall und von jedem gelöscht werden. Beim Löschen zu unterscheiden sind VAS-Applikationen der Implementierungsklassen DF_PT und DF_AD bzw. der Implementierungsklasse EFJTRANSFER.
Ablauf des Löschens einer solchen VAS-Applikation für die Implementierungsklasse DF PT oder DF AD:
1. Der Karteninhaber führt eine VAS-Karte in ein Serviceterminal ein.
2. Das Serviceterminal prüft, ob ein VAS-Container vorhanden ist:
• SELECT FILE < AIDVAS > (Fehlermeldung wenn VAS-Container nicht selektierbar) • READ RECORD < EFJD > (Auslesen der VAS-Container ID)
3. Das Serviceterminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. Eine davon lautet Löschen VAS-Applikation. Diese wählt der Karteninhaber aus. Nun werden dem Karteninhaber alle VAS-Applikationen aller Implementierungsklassen, die im VAS-Container geladen sind, angezeigt, und es wird auf eine Auswahl gewartet. Dazu wird die Operation Ansehen VAS-
Applikationen aktiviert. Der Karteninhaber wählt eine VAS-Applikation A der Implementierungsklasse DF_PT oder DF_AD mit AIDA aus. Das Objekt, in dem die VAS-Applikation geladen ist, heiße DF_A.
4. Nach der Selektion des DF_A authentisiert sich das Serviceterminal: • SELECT FILE < PIXA >
• GET CHALLENGE
• EXTERNAL AUTHENTICATE < KS0(Zufallszahl), KID von Kso >
5. Nun wird der Inhalt der Dateien aus DF_A gelöscht (für EF_KEY, EFJNTERNAL und EFJ/ALUE sind der KLVASP notwendig, deshalb wird dieser zuerst vom System Operator gelöscht):
• UPDA TE KEY < KID von KLVASP, "00...00" > UPDATE KEY < KID von KRVASP, "00...00" > GET CHALLENGE
EXTERNAL AUTHENTICATE < KLvAsp(Zufallszahl), KID von KLVASP UPDATE RECORD < SFI von EFJNFO des DF_A, "00...00" > UPDATE RECORD < SFI von EFJNTERNAL des DF_A, "00...00" > UPDATE RECORD < SFI von EFJVALUE des DF_A, "00...00" > 6. Nach einem erfolgreichen Schreiben in die EFs wird abschließend vom Serviceterminal der Eintrag der VAS-Applikation aus EFJDIR gelöscht:
• SELECT FILE < AIDVAs > (Fehlermeldung wenn VAS-Container nicht selektierbar)
• UPDATE RECORD < SFI von EFJDIR des DFJVAS, Nummer Record mit FIDDF_A, "00...00", FIDDF A >
Die Verbindung von PIXA zum DF_A wird dadurch aufgelöst, so daß SELECT FILE mit dem PIXA nicht mehr möglich ist.
Nun für die Implementierungsklasse EFJTRANSFER:
Eine VAS-Applikation der Implementierungsklasse EFJTRANSFER soll nach R&R nur auf expliziten Wunsch eines Karteninhabers an einem Händlerterminal oder Serviceterminal gelöscht werden (auch wenn dies technisch durch beide möglich wäre). Das Löschen eines Objektes aus EFJTRANSFER wird insbesondere dann notwendig, wenn der Transferspeicher keinen Platz mehr enthält für die Speicherung eines neuen Objektes (z.B. einen Gutschein oder eine Quittung). Das Löschen geschieht immer indirekt über das Ergänzungskommando TAKE. Dieses Kommando markiert nur ein Objekt als entfernt. Damit ist es zum Überschreiben durch ein nachfolgendes Ergänzungskommando TRANSFER freigegeben.
Ablauf des Löschens dieser VAS-Applikation: 1. Der Karteninhaber führt eine VAS-Karte in ein Terminal ein, welches den Inhalt von EFJTRANSFER darstellen kann (Spezialfall von Operation Ansehen VAS- Applikationen).
2. Das Terminal prüft, ob ein VAS-Container vorhanden ist:
• SELECT FILE < AIDVAS > (Fehlermeldung wenn VAS-Container nicht selektierbar)
• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID)
3. Das Terminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. Eine davon lautet Löschen VAS-Applikation. Diese wählt der Karteninhaber aus. Nun werden dem Karteninhaber zumindestens die VAS-Applikationen der Implementierungsklasse EFJTRANSFER angezeigt, und es wird auf eine Auswahl gewartet. Dies wird durch einen Spezialfall der Operation Ansehen VAS-Applikationen realisiert. Der Karteninhaber wählt ein Objekt der
Implementierungsklasse mit einem Gutschein bzw. einer Quittung aus. Dieses Objekt besitze die Recordnummer A. Der Karteninhaber bestätigt die Auswahl.
4. Das Terminal markiert den Record mit Recordnummer A als entfernt, indem es A, eine von ihm berechnete Zufallszahl, seine PIX und Terminal ID mit dem
Kommando TAKE übermittelt:
• TAKE < A, Zufallszahl, PIX, Terminal ID >
Nun steht der als entfernt markierte Record wieder zur Verfügung zur Aufnahme für einen neuen Gutschein oder eine Quittung.
Nachfolgend der Ablauf der Selektion einer VAS-Applikation:
Ist eine VAS-Applikation A der Implementierungsklassen DF_PT oder DF_AD in den VAS-Container mit der Operation Laden VAS-Applikation geladen worden, kann sie zweistufig von einem Terminal selektiert werden. Zuerst wird der VAS- Container selektiert und danach die VAS-Applikation mit ihrer PIXA: 1. SELECT FILE < AIDVAS > (Fehlermeldung wenn VAS-Container nicht selektierbar)
Ein Serviceterminal kann die Echtheit des VAS-Containers prüfen. Dazu verlangt ein Serviceterminal eine interne Authentifizierung des VAS-Containers:
• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID)
• INTERNAL AUTHENTICATE < Zufallszahl, KID von KAUT >
Das Serviceterminal prüft die Antwort und bricht im Fehlerfall (mit
Fehlermeldung) ab.
2. SELECT FILE < PIXA > (Fehlermeldung, falls VAS-Applikation A nicht in den VAS-Container geladen ist)
Ein Händlerterminal (welches nicht über den KGKAUT verfügt) kann indirekt die Echtheit des VAS-Containers durch die Echtheitsprüfung der VAS-Applikation A feststellen. Denn eine VAS-Applikation kann nur an einem Serviceterminal geladen worden sein, die beim Ladevorgang die Echtheit des VAS-Containers geprüft hat. Die Echtheitsprüfung der VAS-Applikation A kann auf den Test des Händerterminals zurückgeführt werden, ob der VAS-Container den Schlüssel KLVASP oder den KR ASp für die VAS-Applikation A enthält. Dies kann das Händlerterminal z.B. kontrollieren durch:
• INTERNAL AUTHENTICATE < Zufallszahl, KID von KRVASP oder KLVASP >
Um zu testen, ob eine VAS-Applikation A im VAS-Container geladen ist, kann sie probeweise selektiert werden; aufgrund der Fehlermeldung der Antwortnachricht von SELECT FILE kann daraus geschlossen werden, daß sie nicht vorhanden ist. Eine Selektion einer VAS-Applikation der Implementierungsklasse EFJTRANSFER ergibt sich implizit durch die Operation Ansehen VAS-Applikationen und das Speichern der Daten im Terminal. Da das Terminal die Recordnummer von jedem angezeigten Objekt aus EFJTRANSFER kennt, kann per Recordnummer ein beliebiges Objekt zur Weiterverarbeitung durch Bezugnahme auf die Recordnummer selektiert werden.
Nachfolgend der Ablauf des Ansehens einer VAS-Applikation:
Die Operation Ansehen von VAS-Applikationen listet an einem Serviceterminal sämtliche VAS-Applikationen der Implementierungsklassen DFJPT, DF_AD und EFJTRANSFER auf. An einem Händlerterminal können nur die VAS-Applikationen der Implementierungsklasse EFJTRANSFER angezeigt werden, da für diese kein Zugriffsschutz existiert, und optional Applikationen der Implementierungsklasse DF_PT bzw. DF_AD, für die das Händlerterminal Leserechte besitzt (Besitz von
KRVASP)-
Ablauf einer solchen VAS-Applikation:
1. Der Karteninhaber führt eine VAS-Karte (Chipkarte mit gültigem VAS-Container) in das Terminal ein.
2. Das Serviceterminal prüft, ob ein VAS-Container vorhanden ist:
• SELECT FILE < AIDVAS > (Fehlermeldung wenn VAS-Container nicht selektierbar) • READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID)
Optional wird die Gültigkeit des VAS-Containers geprüft. Dazu verlangt das Serviceterminal eine interne Authentifizierung des VAS-Containers: • INTERNAL AUTHENTICATE < Zufallszahl, KID von KAUT >
Das Serviceterminal prüft die Antwort und bricht im Fehlerfall (mit Fehlermeldung) ab.
3. Das Serviceterminal stellt dem Karteninhaber mehrere Optionen zur Auswahl. Eine davon lautet Ansehen VAS-Applikationen. Diese wählt der Karteninhaber aus.
4. Das Serviceterminal authentisiert sich:
• GET CHALLENGE
• EXTERNAL AUTHENTICATE < Ks0(ZufallszahI), KID von Kso >
5. Für VAS-Applikationen der Implementierungsklassen DF_PT und DF_AD werden über den Inhalt von EFJDIR gesteuert nacheinander die einzelnen VAS-
Applikationen selektiert und nach einer externen Authentifizierung mit dem Schlüssel Kso der Inhalt der einzelnen EFJNFO (oder ein Teil davon nach R&R) sowie EFJVALUE angezeigt:
• Für i = 0, .... nrD,R - 1
• READ RECORD < SFI von EFJDIR, i >
In der Antwortnachricht steht PIXA, die "00..00" ist, wenn in das entsprechende DF keine VAS-Applikation geladen ist. Alternativ zum READ RECORD aus EFJDIR kann eventuell auch ein SEEK Kommando benutzt werden.
• Wenn PIXA ungleich "00..00"
• SELECT FILE < PIXA >
• READ RECORD < SFI von EFJNFO, 0 >
• Anzeigen (eventuell eines Teils) der Antwortnachricht • READ RECORD < SFI von EFJ/ALUE, 0 >
• SELECT FILE < AlDVAS > 6. Für VAS-Applikationen der Implementierungsklasse EF_TRANSFER wird der Inhalt (oder ein Teil davon nach R&R) des EFJTRANSFER eines jeden Records gelesen:
• SELECT FILE < AIDVAS >
• Für i = 0 nrEF_TRANSFER - 1
• READ RECORD < SFI von EFJTRANSFER, i >
(in der Antwortnachricht steht Inhalt des i-ten Records von EFJTRANSFER)
• Wenn Inhalt nicht leer ist, wird der Inhalt interpretiert (z.B. entnommen/verfallen) angezeigt.
Das Ansehen der Applikationen der Implementierungsklasse DF_PT bzw. DF_AD, für die das Händlerterminal Leserechte besitzt (Besitz von KRVASP). erfolgt wie beschrieben - mit zwei Abweichungen: Zur externen Authentifizierung wird anstelle des Kso, über den nur der System Operator verfügt, der Schlüssel KRVASP benutzt.
Verfügt ein Händlerterminal nicht über den KGKAUT und möchte dennoch die
Echtheit der VAS-Applikationen prüfen, kann das Händlerterminal anstelle der internen Authentifizierung die Authentifizierung (zumindest einer) VAS-Applikation verlangen. Dies geschieht, wie aufgeführt, durch Kenntnis der Karte des entsprechenden KRVASP oder K VASP Schlüssels.
Für VAS-Applikationen der Implementierungsklasse EFJTRANSFER wird der Inhalt (oder ein Teil davon nach R&R) des EFJTRANSFER jedes Records nacheinander aufgelistet, wie vorher beschrieben.
Die Operation Interpretieren VAS-Applikationen verläuft dazu analog. Das Terminal stellt dazu dem Karteninhaber eine Option Interpretieren VAS-Applikationen zur Auswahl. Zusätzlich zu den Daten, die durch die Operation Ansehen sichtbar werden, können auch Daten aus EFJNFO und EFJVALUE, die einer Interpretation durch den VAS-Provider bedürfen (z.B. extern verschlüsselte Daten) und Daten aus EFJNTERNAL (z.B. Meilen der vergangenen Jahre bei Miles & More), dargestellt werden. Dies ist jedoch nur für die VAS-Applikationen möglich, für die ein VAS-Provider (nach seinen eigenen Vorstellungen) am Terminal geeignete
Schlüssel zur Verfügung stellt. Zum Lesen des EFJNTERNAL einer VAS- Applikation ist der Schlüssel KLVASP (externe Authentifizierung) notwendig. Für extern verschlüsselte Daten innerhalb der Elementary Files EFJNFO, EFJNTERN und EFJVALUE sowie des Transferspeichers EFJTRANSFER werden die entsprechenden Schlüssel des VAS-Providers benötigt. Das Terminalprogramm kann anhand der PIX einer selektierten VAS-Applikation leicht entscheiden, für welche Applikationen Schlüssel für die Interpretation der Daten zur Verfügung stehen.
Die Operation Übertragen von VAS-Applikationen bedeutet das Übertragen aller oder ausgewählter VAS-Operationen einer Quell-Karte auf eine Ziel-Karte an einem Serviceterminal. Bedingung ist hierbei, daß im VAS-Container der Zielkarte keine VAS-Applikationen geladen sind und nach der Übertragung auf der Quell- Karte alle VAS-Applikationen gelöscht werden. Beides kann durch sukzessive Anwendung der Operation Löschen einer VAS-Applikation erreicht werden. Außerdem muß die Echtheit der VAS-Karten geprüft werden und die Ziel-Karte über ausreichend Speicherplatz verfügen. Die Operation Übertragung selbst basiert im wesentlichen auf einer Erweiterung der Operation Ansehen von VAS- Applikationen, bei der zusätzlich die Daten aus EFJNTERNAL und die Schlüssel KLVASP ur>d KRVASP gelesen werden, und einer wiederholten Anwendung der Operation Laden einer VAS-Applikation.
Mit den VAS-Daten wird auch die VAS-Container ID mit auf die Ziel-Karte übertragen, damit sich VAS-Applikationen auf der Ziel-Karte genau so verhalten wie auf der Quell-Karte. Der Grund hierfür ist, daß von einem VAS-Provider abgeleitete Schlüssel sich auf die VAS-Container ID stützen, die Schlüssel aber unverändert kopiert werden. Außerdem möchte ein VAS-Provider seine Buchführung im Hintergrundsystem nicht ändern, da er VAS-Karten üblicherweise über die VAS-Container ID identifiziert. Unbedingt zu beachten ist bei der Übertragung der VAS-Container ID, daß diese systemweit eindeutige Nummer auf der Quell-Karte gelöscht wird.
Um speziell das Elementary File EFJNTERNAL und die Schlüssel KLVASP und KRVASP lesen zu können, überschreibt das Serviceterminal nach einer externen Authentifizierung mit dem Schlüssel Kso (analog wie bei der Operation Löschen einer VAS-Applikation) zuerst die Schlüssel KLVASP und kann dann nach einer erneuten Authentifizierung mit KLVASP die Daten aus EFJNTERNAL übertragen.
Zusätzlich zu den VAS-Applikationen der Implementierungsklassen DF_PT und DF_AD muß die Datei EFJTRANSFER übertragen werden. Dazu werden mit der Operation Entnehmen nacheinander die Objekte dieser Implementierungsklasse entfernt, die nicht bereits als entfernt oder verfallen markiert sind, ihre Signatur mit KSIG_VASC geprüft und in das EFJTRANSFER der Ziel-Karte übertragen. Auf der Ziel-Karte werden allerdings die Objekte als nicht entnommen gekennzeichnet, damit sie weiterhin gültig bleiben.
Schließlich müssen noch die globalen Daten des VAS-Containers übertragen werden. Insbesondere muß der Sequenzzähler der Ziel-Karte auf den Wert der Quell-Karte eingestellt werden.
Nachfolgend das Verfahren des Aufbringens von VAS-Daten:
Es gibt drei mögliche Fälle für das Aufbringen von VAS-Daten an einem Händlerterminal, die von der Art der VAS-Applikation abhängen.
Zunächst das Erwerben im Falle der Implementierungsklasse DF_PT oder DF_AD
Es sollen von einem VAS-Provider Daten in eine VAS-Applikation A der Implementierungsklasse DF_PT oder DF_AD geschrieben werden. Ablauf des Aufbringens von VAS-Daten: 1. Der Karteninhaber führt eine VAS-Karte in ein Händlerterminal ein. - Cύ> -
2. Das Händlerterminal prüft, ob ein VAS-Container vorhanden ist:
• SELECT FILE < AIDVAS > (Fehlermeldung wenn VAS-Container nicht selektierbar)
• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID)
3. Es wird die Echtheit des VAS-Containers geprüft.
Ist das Händlerterminal selbst in Besitz des Masterkeys KGKAUT, kann es eine interne Authentifizierung des VAS-Containers verlangen:
• INTERNAL AUTHENTICATE < Zufallszahl, KID von KAUT >
Ein Händlerterminal (welches nicht über den KGKAUT verfügt) kann indirekt die
Echtheit des VAS-Containers durch die Echtheitsprüfung der VAS-Applikation A feststellen. Denn eine VAS-Applikation kann nur an einem Serviceterminal geladen worden sein, die beim Ladevorgang die Echtheit des VAS-Containers geprüft hat. Die Echtheitsprüfung der VAS-Applikation A kann auf den Test des Händlerterminals zurückgeführt werden, ob der VAS-Container den Schlüssel
KLVASP ° er den KRVASP für die VAS-Applikation A enthält. Dies kann das Händlerterminal z.B. kontrollieren durch:
• SELECT FILE < PIXA > (Fehlermeldung, falls VAS-Applikation A nicht in den VAS-Container geladen ist)
• INTERNAL AUTHENTICATE < Zufallszahl, KID von KRVASP oder KLVASp >
Das Händlerterminal prüft die Antwort und bricht im Fehlerfall (mit Fehlermeldung) ab. - 6 - 4. Das Händlerterminal selektiert die VAS-Applikation A, authentisiert sich und beschreibt die Elementary Files, die für die Abwicklung der Transaktion notwendig sind:
• SELECT FILE < PIXA > (entfällt, wenn bereits in Schritt 3 durchgeführt)
• GET CHALLENGE
• EXTERNAL AUTHENTICATE < KLVASp(Zufallszahl), KID von KLVASP >
• optional: UPDATE RECORD < SFI von EFJNFO des DF_X, Daten >
• optional: UPDATE RECORD < SFI von EFJNTERNAL des DF_X, Daten > • optional: UPDATE RECORD < SFI von EFJVALUE des DF_X, Daten >
Als nächstes das Erwerben im Falle der Implementierungsklasse EFJTRANSFER
Speziell für VAS-Applikationen der Implementierungsklasse EFJTRANSFER (Applikationsklasse Gutschein) muß ein VAS-Provider keine proprietäre Dateistruktur DF_X für seine Applikation belegen. Die Folge ist, daß ein Karteninhaber nicht vor der Nutzung einer VAS-Applikation Gutschein an ein Serviceterminal gehen muß, um eine VAS-Applikation zu laden. Er kann dagegen direkt am Händlerterminal sich einen Gutschein oder eine Quittung ausstellen und diese an einem anderen Terminal erstatten (durch die Operation Entnehmen) lassen oder den Gutschein bzw. die Quittung nur einfach vorweisen (durch Lesen). Durch das Aufbringen von VAS-Daten erfolgt somit ein implizites Laden von VAS- Applikationen der Implementierungsklasse EFJTRANSFER. Für diese Applikationsklasse existiert die Implementierungsklasse EFJTRANSFER, die aus einzelnen Objekten der Art Record besteht. Ein Eintrag in EFJTRANSFER ist ausschließlich durch das Kommando TRANSFER möglich. Das Händlerterminal muß dazu im Besitz eines gültigen Entwerter-Schlüssels KDEC sein und über eine PIXA der VAS-Applikation A verfügen.
Ablauf des Aufbringens von VAS-Daten:
1. Der Karteninhaber führt eine VAS-Karte in ein Händlerterminal ein.
2. Das Händlerterminal prüft, ob ein VAS-Container vorhanden ist: • SELECT FILE < AIDVAS (Fehlermeldung wenn VAS-Container nicht selektierbar)
• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container Nummer)
3. Das Händlerterminal liest die Sequenznummer, die zusätzlich in den MAC aus Schritt 4 eingeht:
• READ RECORD < SFI von EF_SEQ, 0 > (Auslesen der Sequenznummer)
4. Mit dem Kommando TRANSFER wird in EFJTRANSFER ein Record geschrieben:
• TRANSFER <Transaktionsdatum, Verfallsdatum, Erzeugercode, Daten, PIXA, MAC mit KDEC>
5. Das Händlerterminal kann durch Prüfung der Antwortnachricht des TRANSFER Kommandos prüfen, ob der VAS-Container echt ist (d.h. in Besitz des gemeinsamen Geheimnisses KDEC ist). Wir verweisen hierzu auch auf die vorher beschriebene Antwortnachricht des Kommandos TRANSFER.
Schließlich das Erwerben von VAS-Daten durch Entwerten
Ein VAS-Provider kann durch einen Entwertevorgang mit dem Kommando TRANSFER im Transferfeld EFJTRANSFER ein Anrecht (z.B. Gutschein oder Quittung) erzeugen, das von einem anderen VAS-Provider weiter verwertet werden kann. Entwertet werden Daten aus dem EFJVALUE bzw. EFJNFO der VAS- Applikation A des entwertenden VAS-Provider. Der Karteninhaber erwirbt in Form eines Objektes in EFJTRANSFER das Anrecht.
Ablauf des Aufbringens von VAS-Daten:
1. Der Karteninhaber führt eine VAS-Karte in ein Händlerterminal ein. 2. Das Händlerterminal prüft, ob ein VAS-Container vorhanden ist:
• SELECT FILE < AIDVAS > (Fehlermeldung wenn VAS-Container nicht selektierbar)
• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID)
3. Das Händlerterminal liest die Sequenznummer, die zusätzlich in den MAC aus Schritt 4 eingeht:
• READ RECORD < SFI von EF_SEQ, 0 > (Auslesen der Sequenznummer)
4. Das Händlerterminal selektiert die VAS-Applikation A:
• SELECT FILE < PIXA > (Fehlermeldung, falls VAS-Applikation A nicht in den VAS-Container geladen ist)
5. Das Händlerterminal nutzt das Kommando TRANSFER zum Entwerten der Daten aus dem EFJVALUE bzw. dem EFJNFO.
• TRANSFER < Daten, MAC mit KDEC >
Die Zusammensetzung der Kommandonachricht von TRANSFER wurde bereits beschrieben. Die Berechtigung zum Entwertevorgang erlangt das Terminal, wenn es eine korrekte Signatur über die Daten mit dem Schlüssel KDEC bilden kann. Diese wird durch den VAS-Container geprüft.
Bei Erfolg wird vom VAS-Container ein Record in EFJTRANSFER angelegt sowie die Sequenznummer inkrementiert.
6. Das Händlerterminal kann durch Prüfung der Antwortnachricht des TRANSFER Kommandos prüfen, ob der VAS-Container echt ist (d.h. in Besitz des gemeinsamen Geheimnisses KDEC ist). Und nun noch das Verfahren zum Entwerten von VAS-Daten. Es gibt zwei Arten von Entwertungsvorgängen:
Zum einen können VAS-Daten für VAS-Applikationen der Implementierungsklasse DF_PT oder DF_AD durch den zugehörigen VAS-Provider entwertet werden durch die Operation Entwerten, d.h. Erwerben von VAS-Daten durch Entwerten. Dadurch wird ein Wert verbraucht, wobei ein potentielles Anrecht auf einen weiteren Wert entsteht.
Zum anderen können VAS-Daten aus dem EFJTRANSFER einmalig entnommen werden mit dem Ergänzungskommando TAKE. In diesem Fall wird das Anrecht aufgebraucht, die Daten bleiben für etwaige weitere Verwendung (z.B. rückerstattetes Ticket wird zur Rückfahrt noch benötigt) im Transferfeld als entnommen gekennzeichnet stehen, bis sie bei Bedarf von anderen Objekten überschrieben werden.
Ablauf des Entwertens von VAS-Daten durch das Kommando TAKE:
1. Der Karteninhaber führt eine VAS-Karte in ein Händlerterminal ein.
2. Das Händlerterminal prüft, ob ein VAS-Container vorhanden ist:
• SELECT FILE < AIDvAS > (Fehlermeldung wenn VAS-Container nicht selektierbar)
• READ RECORD < SFI von EFJD, 0 > (Auslesen der VAS-Container ID)
3. Zunächst liest das Händlerterminal die zur Verfügung stehenden Objekte aus EFJTRANSFER aus mit dem Spezialfall der Operation Ansehen VAS- Applikationen, um zu entscheiden, ob ein gesuchtes Objekt enthalten ist. Alternativ kann mit dem Kommando SEEK nach einem Muster gesucht werden. Das Terminal kennt im Erfolgsfall die Nummer i des gesuchten Records. - > -
4. Das Terminal markiert den Record mit Recordnummer i als entfernt, indem es i, eine von ihm berechnete Zufallszahl, seine PIX und Terminal ID mit dem Kommando TAKE übermittelt:
• TAKE < i, Zufallszahl, PIX, Terminal ID >
Das Händlerterminal nutzt das Kommando TAKE zum Lesen der Daten aus dem EFJTRANSFER bei gleichzeitigem Kennzeichnen der Daten als entnommen. Die Ausführung des Kommandos bewirkt zusätzlich die Erzeugung von zwei verschiedenen Kryptogrammen C1 und C2.
Das Kryptogramm C-, wird durch den VAS-Container mit dem Schlüssel KSIG_VASC berechnet. Damit kann der Einreicher des entnommenen, mit C^ signierten Objektes sich beim System Operator die Einmaligkeit und Echtheit nachweisen lassen. Die Einmaligkeit und Echtheit der Transaktion ergibt sich aus dem Kryptogramm des VAS-Providers, von dem das Objekt ursprünglich stammt (und die von der Karte geprüft wurde, siehe TRANSFER), und der Führung eines Sequenzzählers über die Transaktionen sowie dem Kryptogramm C1 durch die Karte bei der Entnahme.
Das Kryptogramm C2 wird durch den VAS-Container mit dem Schlüssel KDEC berechnet, der von dem VAS-Container aus KGKDEC, PIX und Terminal ID abgeleitet wird. Durch Kenntnis des gemeinsamen Geheimnisses KDEC kann der VAS-Container dem Terminal gegenüber direkt die Echtheit des VAS-Containers beweisen. Da beim TRANSFER Kommando ebenfalls geprüft wird, daß nur echte Gutscheine bzw. Quittungen in einen echten VAS-Container gepeichert werden, kann daraus die Echtheit des entnommenen Objektes gefolgert werden. Da C2 indirekt über die Sequenznummer, das Entnommen-Bit und die VAS- Container ID gebildet wird, kann der VAS-Container dem Terminal sogar die Einmaligkeit des entnommenen Objektes nachweisen.
Die Berechtigung zum Entnehmen mit dem Kommando TAKE hat jeder. - 12 -
Am Serviceterminal ist ferner die Deaktivierung bzw. Aktivierung eines Paßwortoder PIN-Schutzes für das Lesen von VAS-Applikationen der Implementierungsklassen DF_PT und DF_AD möglich. Außerdem kann die PIN des VAS-Containers vom Karteninhaber durch der Kenntnis der PIN geändert werden und vom System Operator mittels externer Authentifizierung durch Ks0 zurückgesetzt werden. Als PIN oder Paßwort sind auch nicht-numerische Zeichen oder Zeichenketten beliebiger Länge verwendbar.

Claims

- -b - Patentansprüche
1. Chipkarte, die zur Durchführung von Transaktionen dient, bei denen geldwerte Einheiten oder andere nicht-monetäre Ansprüche repräsentierende
Wertdaten zwischen dem Karteninhaber und mindestens einem Transaktionspartner (Service-Provider) übertragen oder dem Service-Provider zur Verifizierung der Ansprüche vorgewiesen werden, wobei die Chipkarte einen Speicher umfaßt, in dem zur Durchführung der Transaktionen erforderliche Daten abgespeichert werden, und die Chipkarte dadurch gekennzeichnet ist, daß sie folgendes aufweist: eine Einrichtung zum Laden von einer oder mehreren Kartenanwendungen (VAS-Applikationen) auf die Karte, die jeweils die Durchführung von Transaktionen zwischen dem Karteninhaber und einem oder mehreren Service-Provider ermöglichen.
2. Chipkarte nach Anspruch 1 , bei der die Einrichtung zum Laden folgendes aufweist: eine darin abgespeicherte Datenstruktur (DFJVAS, VAS-Container), die aufweist: eine Teilstruktur (DF_PT, DF_AD, VAS-Applikation), in die zur Ermöglichung der Durchführung einer Transaktion zwischen dem Karteninhaber und einem Service-Provider erforderliche Daten (VAS-Daten) geladen werden können; einen Definitionsdatensatz, der Informationen über die Art und/oder
Struktur der in der Teilstruktur (VAS-Applikation) abgespeicherten Daten enthält; wobei der Definitionsdatensatz ferner aufweist: eine die Datenstruktur (VAS-Container) und/oder die Chipkarte identifizierende Kennung (Container-ID); und mindestens einen System-Schlüssel (Kso), der die Integrität des
Definitionsdatensatzes und/oder der Datenstruktur (VAS-Container) gegen Modifikationen absichert. -T-4 -
3. Chipkarte nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß sie ferner aufweist: einen Transfer-Speicherbereich (EFJTRANSFER) zur Aufnahme von bei der Durchführung der Transaktion auszutauschenden oder vorzuweisenden die geldwerte Einheiten oder nicht monetären Ansprüche repräsentierenden Daten; und eine Einrichtung zum Schreiben von Daten in den Transferspeicher in Reaktion auf ein Schreibkommando (Transfer).
4. Chipkarte nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß sie weiterhin mindestens eines der folgenden Merkmale aufweist: eine Einrichtung zum Laden von für die Durchführung von Transaktionen erforderlichen Daten in die Teilstruktur unter Verwendung des mindestens einen Systemschlüssels; eine Einrichtung zum Schreiben von Daten in den Definitionsdatensatz zum Anpassen der Daten des Definitionsdatensatzes an die in die Teilstruktur geladenen Daten; eine Einrichtung zum Generieren einer weiteren Teilstruktur, in die zur
Durchführung einer Transaktion erforderliche Daten geladen werden können, in dem Speicher der Karte; und/oder eine Einrichtung zur dynamischen Speicherverwaltung auf der Karte.
5. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß es sich bei den Teilstrukturen (VAS-Applikationen) um voneinander unabhängige Teilstrukturen handelt, die jeweils einem bestimmten Service-Provider zugeordnet sind, der Definitionsdatensatz mittels des mindestens einen Systemschlüssels
(Kso) Qegen Modifikationen geschützt ist und nur mittels dieses Schlüssels modifiziert werden kann, und daß das Laden der Teilstrukturen (VAS-Applikationen) nur unter Verwendung des im Definitionsdatensatz enthaltenen Systemschlüssels erfolgen kann.
6. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch ge- kennzeichnet, daß der Definitionsdatensatz ferner mindestens eines der folgenden Merkmale aufweist: mindestens einen Authentifizierungsschlüssel (KAUT) zur Authentifizierung der Berechtigung der Chipkarte gegenüber einem Terminal und/oder zur Authentifizierung der Berechtigung eines Terminals gegenüber der Chipkarte; mindestens einen Signierschlüssel (KS|G VASC) zum Signieren von aus dem Transferspeicher entnommenen Daten; einen Schlüsselerzeugungs-Schlüssel (KGKDEC) zur Erzeugung von terminal- und applikationsspezifischen Schlüsseln zur Überprüfung der Berechtigung eines Schreibvorgangs in den Transferspeicher und/oder einer Entwertung von Wertdaten; eine PIN zur Verifikation der Berechtigung eines Transaktionsvorgangs durch den Karteninhaber, daß der Systemschlüssel (Kso), der Authentizifierungsschlüssel (KAUT), der Signierschlüssel (KS|G VASC) und der Schlüsselerzeugungs-Schlüssel (KGKDEC) kartenindividuelle oder datenstruktur-(DFJVAS)-spezifιsche Schlüssel sind, und daß die Teilstruktur (VAS-Applikation) mindestens eines der folgenden Merkmale aufweist: mindestens einen Wertspeicher (EFJVALUE) zur Aufnahme von Wertdaten; mindestens einen Intem-Speicher (EFJNTERNAL) zur Aufnahme von internen die Teilstruktur betreffenden Daten; mindestens einen Infospeicher (EFJNFO) zur Aufnahme von nicht internen die Teilstruktur betreffenden Daten; einen Schlüsselspeicher (EFJXEY) zur Aufnahme mindestens eines
Schlüssels (KLVASP. KRVASP). die Schreib- und/oder Lesevorgänge in den oder aus dem Wertspeicher, und/oder dem Intern-Speicher und/oder dem Info-Speicher absichern, und daß die Chipkarte ferner umfaßt: eine Einrichtung zum Schreiben und/oder Lesen von Daten in den oder aus dem Wertspeicher, dem Intern-Speicher und dem Infospeicher, und daß die Einrichtung zum Laden umfaßt: eine Einrichtung zum Schreiben der Schlüssel in den Schlüsselspeicher unter Absicherung durch den mindestens einen Systemschlüssel.
7. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch ge- kennzeichnet, daß die Teilstruktur mindestens eines der folgenden Merkmale aufweist: einen Schlüssel (KLVASP) zum Überprüfen der Schreibberechtigung von Daten in die Teilstruktur; einen Schlüssel (KRVASp) zum Überprüfen der Leseberechtigung von Daten aus der Teilstruktur.
8. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die im Schlüsselspeicher abgespeicherten Schlüssel für die jeweilige Teilstruktur spezifisch sind und daß die mindestens eine Teilstruktur (VAS-Applikation) das Durchführen von
Transaktionen mittels mindestens eines der spezifischen Schlüssel (KLVAsp. KRVAsp) absichert, der für die jeweilige Teilstruktur (VAS-Applikation) spezifisch und von den Schlüsseln anderer Teilstrukturen (VAS-Applikationen) unabhängig ist.
9. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Karte mehrere der Teilstrukturen (VAS-Applikationen) aufweist, die jeweils zur Durchführung von Transaktionen zwischen einem bestimmten Service- Provider und dem Karteninhaber dienen, und daß das Durchführen von Transaktionen das Schreiben und/oder Lesen von
Daten in das bzw. aus dem Transferfeld und/oder das Schreiben und/oder Lesen von Daten in den bzw. aus dem Wertspeicher umfaßt. - 11 -
10. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß sie ferner umfaßt: eine Einrichtung zum Durchführen von Transaktionen sowohl zwischen einzelnen Teilstrukturen (VAS-Applikationen) als auch zwischen einer Teilstruktur und einem Service-Provider.
11. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der System-Schlüssel (Kso) nur dem Systembetreiber (System Operator
SO) bekannt ist und ein kartenindividueller und/oder Datenstruktur-(VAS- Container)-spezifischer Schlüssel ist, und daß die weiteren im Definitionsdatensatz enthaltenen Schlüssel kartenindividuelle und/oder Datenstruktur-(VAS-Container)-spezifische Schlüssel sind.
12. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Definitionsdatensatz eines oder mehrere der folgenden Merkmale aufweist: eine die Datenstruktur spezifizierende Identifikationsnummer (EFJD) ein Verzeichnis der in der Datenstruktur enthaltenen Teilstrukturen (EFJDIR), wobei das Verzeichnis teilstrukturspezifische Identifikationsnummern von in der Datenstruktur (VAS-Container) geladenen Teilstrukturen (VAS- Applikationen) enthält, sowie Informationen über den Teil der Datenstruktur (VAS- Container), in dem die Teilstrukturen (VAS-Applikationen) physikalisch gespeichert sind; eine Versionsnummer der Datenstruktur (EFJVERSION).
13. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch ge- kennzeichnet, daß sie mindestens eines der folgenden Merkmale umfaßt: eine Einrichtung zur Durchführung eines Entnahmevorgangs (Take), mittels dessen Daten aus dem Transferspeicher entnommen und/oder entwertet werden; eine Einrichtung zur Erzeugung eines oder mehrerer Echtheitsmerkmale der Daten bei Entnahme bzw. der Entwertung von Daten aus dem Transferspeicher.
14. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Chipkarte zur Generierung der Echtheitsmerkmale folgendes aufweist: einen Signierschlüssel KS|G_VASC zum Erzeugen einer digitalen Signatur über den entnommenen Daten; eine Einrichtung zur Erzeugung einer die Transaktion kennzeichnenden Transaktionsnummer, die zur Erzeugung der digitalen Signatur mitverwendet wird.
15. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Signierschlüssel KS|G_VASC ein aus einem privaten Key-Generating- Key abgeleiteter privater Schlüssel ist und zur Überprüfung der Signatur durch die Serviceprovider öffentliche Schlüssel herangezogen werden.
16. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß sie mindestens eines der folgenden Merkmale umfaßt: eine Einrichtung zur Erzeugung von terminal- und teilstrukturspezifischen Schlüsseln (KDEC) mittels des Schlüsselerzeugungs- Schlüssels (KGKDEC); eine Einrichtung zur Verifizierung der Rechtmäßigkeit und/oder der Absicherung einer Transaktion unter Verwendung mindestens eines der folgenden Merkmale: des terminal- und teilstrukturspezifischen Schlüssels (KDEC), des mindestens einen Authentifizierungsschlüssels (KAUT), des mindestens einen Systemschlüssels (Kso), - 1°ι - des mindestens einen teilstrukturspezifischen Schlüssels (KLVASP.
KRVASP)> des Signierschlüssels (KS|G VASC). der PIN, der Kennung einer Teilstruktur, der Kennung eines Terminals.
17. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Chipkarte ferner mindestens eines der folgenden Merkmale umfaßt: eine Einrichtung zum Authentifizieren der Berechtigung und/oder des Terminals mittels des Authentifizierungsschlüssels bevor ein Lese- oder Schreibvorgang gestartet wird, eine Einrichtung zur Durchführung von Lese- oder Schreibvorgängen, die mit einer digitalen Unterschrift und/oder Verschlüsselung gesichert sind.
18. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Chipkarte ferner mindestens eines der folgenden Merkmale umfaßt: eine Einrichtung zum Aktivieren und Deaktivieren des PIN-Schutzes, eine Einrichtung zum Abändern der PIN.
19. Chipkarte nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Datenstruktur gemäß einem der vorhergehenden Ansprüche von der
Kartenplattform unabhängig ist und die Chipkarte ferner umfaßt: eine Einrichtung zum Übertragen der Datenstruktur oder von Teilen der Datenstruktur auf eine andere Karte.
20. Chipkarte, dadurch gekennzeichnet, daß sie folgendes aufweist: einen Speicherbereich zum Schreiben oder Lesen von Daten in den oder aus dem Speicherbereich zum Transfer von geldwerten Einheiten und/oder - eo — von anderen nicht-monetären Ansprüche repräsentierenden Wertdaten zwischen identischen oder unterschiedlichen Service-Providern.
21. Terminal zur Verwendung mit einer Chipkarte gemäß einem der Ansprüche 1 bis 20, dadurch gekennzeichnet, daß das Terminal umfaßt: eine Einrichtung zum Identifizieren der Datenstruktur (VAS-Container) der Chipkarte sowie zur Identifikation der die Datenstruktur identifizierenden Kennung (Container-ID); und daß es ferner mindestens eines der folgenden Merkmale umfaßt: eine Einrichtung zum Lesen von Daten aus mindestens einer der
Teilstrukturen und/oder dem Definitionsdatensatz und/oder dem Transferspeicher der Karte; eine Einrichtung zum Schreiben von Daten in den Transferspeicher der Karte; eine Einrichtung zum Laden der zur Durchführung von Transaktionen erforderlichen Daten in mindestens eine der Teilstrukturen (VAS-Applikationen) der Karte.
22. Terminal nach Anspruch 21 , dadurch gekennzeichnet, daß es ferner mindestens eines der folgenden Merkmale aufweist: eine Einrichtung zur Durchführung von Transaktionen zwischen einem Service-Provider und dem Karteninhaber, wobei das Durchführen einer Transaktion mindestens einen der folgenden Schritte umfaßt: das Schreiben von Daten in den Wertspeicher, das Schreiben von Daten in den Transferspeicher, das Entnehmen und/oder Entwerten von Daten aus dem Transferspeicher, das Lesen von Daten aus der Teilstruktur, das Lesen von Daten aus dem Transferspeicher.
23. Terminal nach einem der Ansprüche 21 oder 22, dadurch gekennzeichnet, daß es ferner umfaßt: - St eine Einrichtung zur Verifizierung der Rechtmäßigkeit und/oder der
Absicherung einer Transaktion unter Verwendung mindestens eines der folgenden
Merkmale: eines terminal- und teilstrukturspezifischen Schlüssels (KDEC), des mindestens einen kartenindividuellen oder datenstruktur-(DFJVAS)- spezifischen Authentifizierungsschlüssels (KAUT), des mindestens einen kartenindividuellen oder datenstruktur-(DFJVAS)- spezifischen Systemschlüssels (Kso), des mindestens einen teilstrukturspezifischen Schlüssels (KLVASP. KRVASP), des kartenindividuellen oder datenstruktur-(DFJVAS)-spezifischen
Signierschlüssels (KS|G VASC), der kartenindividuellen oder datenstruktur-(DFJVAS)-spezifischen PIN, der applikationsspezifischen Kennung einer Teilstruktur, der terminalspezifischen Kennung eines Terminals.
24. Terminal nach einem der Ansprüche 219 bis 23, dadurch gekennzeichnet, daß die Einrichtung zum Schreiben von Daten in den Transferspeicher aufweist: eine Einrichtung zum Verschlüsseln von Daten unter Verwendung eines terminal- und teilstrukturspezifischen Schlüssels (KDEC) zum Nachweis der Schreibberechtigung.
25. Terminal nach einem der Ansprüche 21 bis 24, dadurch gekennzeichnet, daß es ferner aufweist: eine Einrichtung zum Durchführen eines Entnahmevorgangs von Daten aus dem Transferspeicher, mittels dessen Daten aus dem Transferspeicher entnommen und/oder entwertet werden.
26. Terminal nach einem der Ansprüche 21 bis 25, dadurch gekennzeichnet, daß es ferner mindestens eines der folgenden Merkmale aufweist: eine Einrichtung zum Kennzeichnen von Daten des Transferspeichers als entnommen, eine Einrichtung zum Kennzeichnen von Daten des Transferspeichers als verfallen.
27. Terminal nach einem der Ansprüche 21 bis 26, dadurch gekennzeichnet, daß die Einrichtung zum Durchführen von Transaktionen mindestens eines der folgenden Merkmale aufweist: eine Einrichtung zum Ändern von Wertdaten in der Teilstruktur; eine Einrichtung zum Durchführen von Transaktionen zwischen verschiedenen Service-Providern (Interservices) auf Kosten bzw. zum Nutzen des Karteninhabers.
28. Terminal nach einem der Ansprüche 21 bis 27, dadurch gekennzeichnet, daß es ferner aufweist: eine Einrichtung zum Authentifizieren der Berechtigung des Terminals gegenüber der Karte und/oder der Karte gegenüber dem Terminal unter Verwendung mindestens eines Authentifizierungsschlüssels; eine Einrichtung zum Absichern einer Transaktion durch den Karteninhaber mittels einer PIN; eine Einrichtung zum Aktivieren und Deaktivieren des PIN-Schutzes.
29. Terminal nach einem der Ansprüche 21 bis 28, dadurch gekennzeichnet, daß es ferner mindestens eines der folgenden Merkmale aufweist: eine Einrichtung zum Übertragen einer terminalspezifischen Kennung an die Karte; eine Einrichtung zum Übertragen einer die Teilstruktur spezifizierenden Kennnung an die Karte; eine Einrichtung zum Authentifizieren der Berechtigung unter Verwendung eines terminal- und teilstrukturspezifischen Schlüssels sowie der terminal- und teilstrukturspezifischen Kennung, eine Einrichtung zur Durchführung von Lese- oder Schreibvorgängen, die mit einer digitalen Unterschrift und/oder Verschlüsselung gesichert sind.
30. Terminal nach einem der Ansprüche 21 bis 29, dadurch gekennzeichnet, daß es ferner mindestens eines der folgenden Merkmale aufweist: eine Einrichtung zum Selektieren einer Teilstruktur (VAS-Applikation); eine Einrichtung zum Ansehen einer Teilstruktur auf dem Terminal; eine Einrichtung zum Ansehen der Daten einer Teilstruktur auf dem Terminal; eine Einrichtung zum Laden einer Teilstruktur (VAS-Applikation) auf die
Karte; eine Einrichtung zum Laden einer Kennung einer geladenen Teilstruktur (VAS-Applikation) auf die Karte, eine Einrichtung zum Löschen einer Teilstruktur von der Karte; eine Einrichtung zum Substituieren einer Teilstruktur durch eine andere
Teilstruktur; eine Einrichtung zum Übertragen einer Teilstruktur auf eine andere Karte; eine Einrichtung zum Interpretieren einer Teilstruktur bezüglich ihrer Funktion und ihres zugeordneten Service-Providers sowie zum Lesen und Ansehen von in ihr gespeicherten Informationen.
31. Verfahren zum Durchführen von Transaktionen zwischen einem Karteninhaber und mindestens einem Service-Provider unter Verwendung einer Chipkarte sowie eines Terminals, wobei das Verfahren einen der folgenden Schritte umfaßt:
Vorsehen einer auf der Chipkarte abgespeicherten Datenstruktur, in die zur Ermöglichung der Durchführung der Transaktion zwischen dem Karteninhaber und einem Service-Provider erforderliche Daten (VAS-Daten) geladen werden können, sowie Schreiben oder Lesen von Daten in die/aus der Datenstruktur (VAS- Applikation); - β 4 - Vorsehen eines Transfer-Speicherbereichs (EFJTRANSFER) zur
Aufnahme von bei der Durchführung der Transaktion auszutauschenden oder vorzuweisenden die Geldwerteeinheiten oder nicht-monetären Ansprüche repräsentierenden Daten, sowie Schreiben von Daten in den Transferspeicher oder Lesen von Daten aus dem Transferspeicher.
32. Verfahren nach Anspruch 31 , dadurch gekennzeichnet, daß das Verfahren mindestens einen der folgenden Schritte umfaßt:
Verwendung einer Chipkarte gemäß einem der Ansprüche 1 bis 20; Verwendung eines Terminals gemäß einem der Ansprüche 21 bis 30;
Schreiben oder Lesen von Daten in den/aus dem Wertspeicher oder Intern-Speicher oder Info-Speicher von mindestens einer der Teilstrukturen (VAS- Applikationen).
33. Verfahren nach Anspruch 31 oder 32, dadurch gekennzeichnet, daß es ferner mindestens einen der folgenden Schritte umfaßt:
Authentifizieren der Berechtigung des Terminals und/oder der Chipkarte unter Verwendung mindestens eines Schlüssels;
Absichern der Transaktion durch Verwendung einer digitalen Unterschrift und/oder Verschlüsselung durch Verwendung mindestens eines Schlüssels.
34. Verfahren zum Laden von Daten auf eine Chipkarte unter Verwendung eines Terminals, dadurch gekennzeichnet, daß das Verfahren mindestens einen der folgenden Schritte umfaßt: Laden von Daten in eine Teilstruktur (VAS-Applikation) der Karte;
Schreiben von Daten in den Definitionsdatensatz der Karte.
35. Verfahren zum Laden von Daten nach Anspruch 34, welches mindestens einen der folgenden Schritte umfaßt: Verwendung einer Chipkarte gemäß einem der Ansprüche 1 bis 20;
Verwendung eines Terminals gemäß einem der Ansprüche 21 bis 30.
36. System zur Durchführung von Transaktionen, gekennzeichnet durch: eine Chipkarte gemäß einem der Ansprüche 1 bis 20 und ein Terminal gemäß einem der Ansprüche 21 bis 30.
PCT/DE1997/003012 1996-12-23 1997-12-19 Chipkarte und verfahren zur verwendung der chipkarte WO1998028718A2 (de)

Priority Applications (15)

Application Number Priority Date Filing Date Title
AU57487/98A AU738719B2 (en) 1996-12-23 1997-12-19 Chip card and method for its use
BR9714071-6A BR9714071A (pt) 1997-04-29 1997-12-19 Catão de chip e processo para o uso do cartão de chip
SK860-99A SK86099A3 (en) 1996-12-23 1997-12-19 Chip card and method for its use
IL13017497A IL130174A0 (en) 1996-12-23 1997-12-19 Chip card and method for its use
EP97953671A EP0968485A2 (de) 1996-12-23 1997-12-19 Chipkarte und verfahren zur verwendung der chipkarte
PL97334183A PL334183A1 (en) 1996-12-23 1997-12-19 Integrated circuit containing card and method of using such card
HU0000448A HUP0000448A3 (en) 1996-12-23 1997-12-19 Chip card, terminal for use with it, chip card system and method for using the chip card
JP10528242A JP2000508101A (ja) 1996-12-23 1997-12-19 チップカードおよびチップカード使用方法
EA199900538A EA001837B1 (ru) 1996-12-23 1997-12-19 Чип-карта и способ ее применения
NZ336403A NZ336403A (en) 1996-12-23 1997-12-19 Chip card stores applications for interaction with multiple service provider types
APAP/P/1999/001573A AP1062A (en) 1996-12-23 1997-12-19 Chip card and process for the use of the chip card.
CA002275931A CA2275931A1 (en) 1996-12-23 1997-12-19 Chip card and method for its use
IS5060A IS5060A (is) 1996-12-23 1999-05-28 Kubbkort (chip card) og aðferð til notkunar á því
BG103490A BG63233B1 (bg) 1996-12-23 1999-06-14 Чип-карта и метод за използване на чип-картата
NO993102A NO993102L (no) 1996-12-23 1999-06-22 Chipkort og fremgangsmåte ved anvendelse av chipkort

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE19654187.5 1996-12-23
DE19654187 1996-12-23
DE19718115.5 1997-04-29
DE19718115A DE19718115A1 (de) 1996-12-23 1997-04-29 Chipkarte und Verfahren zur Verwendung der Chipkarte

Publications (2)

Publication Number Publication Date
WO1998028718A2 true WO1998028718A2 (de) 1998-07-02
WO1998028718A3 WO1998028718A3 (de) 1998-10-08

Family

ID=26032753

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1997/003012 WO1998028718A2 (de) 1996-12-23 1997-12-19 Chipkarte und verfahren zur verwendung der chipkarte

Country Status (18)

Country Link
EP (1) EP0968485A2 (de)
JP (1) JP2000508101A (de)
AP (1) AP1062A (de)
AU (1) AU738719B2 (de)
BG (1) BG63233B1 (de)
CA (1) CA2275931A1 (de)
CZ (1) CZ225499A3 (de)
EA (1) EA001837B1 (de)
HU (1) HUP0000448A3 (de)
ID (1) ID23950A (de)
IL (1) IL130174A0 (de)
IS (1) IS5060A (de)
NO (1) NO993102L (de)
NZ (1) NZ336403A (de)
PL (1) PL334183A1 (de)
SK (1) SK86099A3 (de)
TR (1) TR199901431T2 (de)
WO (1) WO1998028718A2 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000030046A1 (en) * 1998-11-18 2000-05-25 Lada Sokota Multifunctional bank card
US7287011B1 (en) 1999-09-07 2007-10-23 Keycorp Limited Application management for multi application devices
EP2199992A1 (de) * 2008-12-19 2010-06-23 Gemalto SA Sichere Aktivierung vor der kontaktlosen Banking-Smartcard-Transaktion

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19929164A1 (de) 1999-06-25 2001-01-11 Giesecke & Devrient Gmbh Verfahren zum Betreiben eines zur Ausführung von nachladbaren Funktionsprogrammen ausgebildeten Datenträgers
DE10324996A1 (de) 2003-06-03 2005-02-17 Giesecke & Devrient Gmbh Chipkarte mit wenigstens einer Applikation
FR2882835B1 (fr) * 2005-03-01 2007-09-07 Softway Sa Procede de transfert securise par carte multimedia securisee
RU2538283C2 (ru) * 2009-04-10 2015-01-10 Конинклейке Филипс Электроникс Н.В. Аутентификация устройства и пользователя
RU2624555C2 (ru) * 2015-08-19 2017-07-04 Общество с ограниченной ответственностью "ОВЕРКОМ" Система обработки данных при отпуске товаров и предоставлении услуг

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1987007061A1 (en) * 1986-05-16 1987-11-19 American Telephone & Telegraph Company Security file system for a portable data carrier
EP0361491A2 (de) * 1988-09-30 1990-04-04 Orga-Kartensysteme GmbH Verfahren zur Programmierung von Chipkarten
FR2640783A1 (fr) * 1988-12-19 1990-06-22 Hitachi Maxell Carte a circuit integre et son procede de commande
WO1992013322A1 (fr) * 1991-01-18 1992-08-06 Gemplus Card International Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur
FR2687816A1 (fr) * 1992-02-24 1993-08-27 Gemplus Card Int Procede de personnalisation d'une carte a puce.
EP0558132A2 (de) * 1992-02-22 1993-09-01 Philips Patentverwaltung GmbH Anordnung zum Datenaustausch
EP0644513A2 (de) * 1993-09-17 1995-03-22 AT&T Corp. Chipkarte für eine Vielzahl von Dienstleistungsanbietern und für entfernte Aufstellung derselben
EP0674290A2 (de) * 1994-02-25 1995-09-27 Fujitsu Limited Kartenartiges Speichermedium und Ausgabeapparat für kartenartiges Speichermedium

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9411586D0 (en) * 1994-06-09 1994-08-03 Zeneca Ltd Coating process

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1987007061A1 (en) * 1986-05-16 1987-11-19 American Telephone & Telegraph Company Security file system for a portable data carrier
EP0361491A2 (de) * 1988-09-30 1990-04-04 Orga-Kartensysteme GmbH Verfahren zur Programmierung von Chipkarten
FR2640783A1 (fr) * 1988-12-19 1990-06-22 Hitachi Maxell Carte a circuit integre et son procede de commande
WO1992013322A1 (fr) * 1991-01-18 1992-08-06 Gemplus Card International Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur
EP0558132A2 (de) * 1992-02-22 1993-09-01 Philips Patentverwaltung GmbH Anordnung zum Datenaustausch
FR2687816A1 (fr) * 1992-02-24 1993-08-27 Gemplus Card Int Procede de personnalisation d'une carte a puce.
EP0644513A2 (de) * 1993-09-17 1995-03-22 AT&T Corp. Chipkarte für eine Vielzahl von Dienstleistungsanbietern und für entfernte Aufstellung derselben
EP0674290A2 (de) * 1994-02-25 1995-09-27 Fujitsu Limited Kartenartiges Speichermedium und Ausgabeapparat für kartenartiges Speichermedium

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000030046A1 (en) * 1998-11-18 2000-05-25 Lada Sokota Multifunctional bank card
US7287011B1 (en) 1999-09-07 2007-10-23 Keycorp Limited Application management for multi application devices
EP2199992A1 (de) * 2008-12-19 2010-06-23 Gemalto SA Sichere Aktivierung vor der kontaktlosen Banking-Smartcard-Transaktion
WO2010070099A1 (en) * 2008-12-19 2010-06-24 Gemalto Sa Secure activation before contactless banking smart card transaction

Also Published As

Publication number Publication date
WO1998028718A3 (de) 1998-10-08
BG103490A (en) 2000-02-29
HUP0000448A2 (hu) 2000-06-28
NZ336403A (en) 2001-09-28
AU5748798A (en) 1998-07-17
ID23950A (id) 2000-06-08
IS5060A (is) 1999-05-28
SK86099A3 (en) 2000-01-18
BG63233B1 (bg) 2001-06-29
NO993102D0 (no) 1999-06-22
JP2000508101A (ja) 2000-06-27
AP1062A (en) 2002-04-25
EA001837B1 (ru) 2001-08-27
CA2275931A1 (en) 1998-07-02
AU738719B2 (en) 2001-09-27
NO993102L (no) 1999-08-23
IL130174A0 (en) 2000-06-01
EA199900538A1 (ru) 2000-06-26
TR199901431T2 (xx) 1999-10-21
CZ225499A3 (cs) 1999-11-17
PL334183A1 (en) 2000-02-14
EP0968485A2 (de) 2000-01-05
AP9901573A0 (en) 1999-06-30
HUP0000448A3 (en) 2000-08-28

Similar Documents

Publication Publication Date Title
EP0992025B1 (de) Transaktionsverfahren mit einem tragbaren Identifizierungselement
DE4119924C2 (de) Verfahren zur Sicherung von ladbaren Guthaben in Chipkarten
DE69814406T2 (de) Tragbare elektronische vorrichtung für systeme zur gesicherten kommunikation und verfahren zur initialisierung der parameter
DE69900169T3 (de) Kreditkartensystem und verfahren
DE69932294T2 (de) Aufzeichnungsmedium mit darauf aufgezeichneten elektronischen Ticketdefinitionen und Verfahren und Vorrichtungen zum Verarbeiten elektronischer Tickets
DE69826318T2 (de) Kartenaktivierung an der verteilungsstelle
DE60218057T2 (de) Sichere handhabung von gespeicherten wertdaten objekten
DE69824437T2 (de) Personalisieren von chipkarten
DE69823649T2 (de) Multi-anwendungs ic-kartensystem
DE60119400T2 (de) Datenverarbeitungssystem, tragbare elektronische Vorrichtung, Zugangsvorrichtung zur tragbaren elektronischen Vorrichtung, und Verfahren zum Gebrauch von Speicherraum
DE19718115A1 (de) Chipkarte und Verfahren zur Verwendung der Chipkarte
EP0306892A1 (de) Schaltungsanordnung mit einer zumindest einen Teil der Anordnung enthaltenden Karte für Geschäfts-, Identifizierungs-und/oder Betätigungszwecke
DE112007002744T5 (de) Gesicherte finanzielle Transaktionen
DE10296919T5 (de) System und Verfahren zur sicheren Rückzahlung
DE19755819C1 (de) Verteiltes Zahlungssystem und Verfahren für den bargeldlosen Zahlungsverkehr mittels einer Börsenchipkarte
DE4243851A1 (de) Verfahren zum Transferieren von Buchgeldbeträgen auf und von Chipkarten
DE102010017861A1 (de) Verfahren zur Handhabung von elektronischen Tickets
WO1998028718A2 (de) Chipkarte und verfahren zur verwendung der chipkarte
EP0713188A2 (de) Verfahren und Chipkarte zum Dokumentieren einer erworbenen Berechtigung
EP1222563A2 (de) System zur ausführung einer transaktion
DE4427039C2 (de) Verfahren zur Bestimmung des aktuellen Geldbetrages in einem Datenträger und System zur Durchführung des Verfahrens
DE69636612T2 (de) Zahlungsverfahren in einer Datenübertragungsanordnung und Anordnung zu dessen Implementierung
EP1141904A1 (de) Verfahren für die sichere handhabung von geld- oder werteeinheiten mit vorausbezahlten datenträgern
DE102006017911B4 (de) Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
DE19616943C2 (de) Adapter-Vorrichtung zum Manipulieren eines Speicherbausteins einer Chipkarte und einen Anbieterterminal zum Erwerb von Waren und/oder Dienstleistungen mittels einer Chipkarte

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: P-291/99

Country of ref document: YU

Ref document number: 97180941.0

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DK EE ES FI GB GE GH GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SZ UG ZW AT BE CH DE DK ES FI FR GB GR IE IT LU

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DK EE ES FI GB GE GH GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SZ UG ZW AT BE CH DE DK ES FI FR GB GR IE IT LU

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: PV1999-2254

Country of ref document: CZ

WWE Wipo information: entry into national phase

Ref document number: 1999/01431

Country of ref document: TR

Ref document number: PA/a/1999/005832

Country of ref document: MX

ENP Entry into the national phase

Ref document number: 2275931

Country of ref document: CA

Ref document number: 2275931

Country of ref document: CA

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 336403

Country of ref document: NZ

Ref document number: 86099

Country of ref document: SK

ENP Entry into the national phase

Ref document number: 1998 528242

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1019997005772

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 199900538

Country of ref document: EA

WWE Wipo information: entry into national phase

Ref document number: 1997953671

Country of ref document: EP

Ref document number: 57487/98

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 09331489

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: PV1999-2254

Country of ref document: CZ

WWP Wipo information: published in national office

Ref document number: 1997953671

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1019997005772

Country of ref document: KR

WWG Wipo information: grant in national office

Ref document number: 57487/98

Country of ref document: AU

WWW Wipo information: withdrawn in national office

Ref document number: 1019997005772

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: 1997953671

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: PV1999-2254

Country of ref document: CZ