MXPA99005832A - Chip card and method for its use - Google Patents
Chip card and method for its useInfo
- Publication number
- MXPA99005832A MXPA99005832A MXPA/A/1999/005832A MX9905832A MXPA99005832A MX PA99005832 A MXPA99005832 A MX PA99005832A MX 9905832 A MX9905832 A MX 9905832A MX PA99005832 A MXPA99005832 A MX PA99005832A
- Authority
- MX
- Mexico
- Prior art keywords
- vas
- data
- card
- key
- terminal
- Prior art date
Links
- 238000003860 storage Methods 0.000 claims description 106
- 230000036961 partial Effects 0.000 claims description 65
- 238000000034 method Methods 0.000 claims description 39
- 230000004048 modification Effects 0.000 claims description 10
- 238000006011 modification reaction Methods 0.000 claims description 10
- 238000011084 recovery Methods 0.000 claims description 8
- 230000001629 suppression Effects 0.000 claims description 6
- 230000004308 accommodation Effects 0.000 claims description 2
- 238000006243 chemical reaction Methods 0.000 claims description 2
- 238000010192 crystallographic characterization Methods 0.000 claims 6
- 241000913730 Kalanchoe latent virus Species 0.000 claims 1
- 241000536399 Tina Species 0.000 claims 1
- 230000003213 activating Effects 0.000 claims 1
- 230000015572 biosynthetic process Effects 0.000 claims 1
- 238000005755 formation reaction Methods 0.000 claims 1
- 102100004847 ARHGEF6 Human genes 0.000 description 28
- 101710038347 ARHGEF6 Proteins 0.000 description 28
- 230000004044 response Effects 0.000 description 23
- HYIMSNHJOBLJNT-UHFFFAOYSA-N Nifedipine Chemical compound COC(=O)C1=C(C)NC(C)=C(C(=O)OC)C1C1=CC=CC=C1[N+]([O-])=O HYIMSNHJOBLJNT-UHFFFAOYSA-N 0.000 description 18
- 241000339782 Tomares Species 0.000 description 7
- 238000009795 derivation Methods 0.000 description 7
- 230000000576 supplementary Effects 0.000 description 7
- 230000000875 corresponding Effects 0.000 description 5
- 238000004519 manufacturing process Methods 0.000 description 5
- 230000002829 reduced Effects 0.000 description 3
- 241000465502 Tobacco latent virus Species 0.000 description 2
- UFLGIAIHIAPJJC-UHFFFAOYSA-N Tripelennamine Chemical compound C=1C=CC=NC=1N(CCN(C)C)CC1=CC=CC=C1 UFLGIAIHIAPJJC-UHFFFAOYSA-N 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000002950 deficient Effects 0.000 description 2
- 230000004438 eyesight Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 230000003068 static Effects 0.000 description 2
- 231100000627 threshold limit value Toxicity 0.000 description 2
- 240000005716 Garcinia dulcis Species 0.000 description 1
- 101700080327 NREP Proteins 0.000 description 1
- 241000209048 Poa Species 0.000 description 1
- 241001125843 Trichiuridae Species 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000001010 compromised Effects 0.000 description 1
- 230000001066 destructive Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002708 enhancing Effects 0.000 description 1
- 235000013410 fast food Nutrition 0.000 description 1
- 235000013305 food Nutrition 0.000 description 1
- 230000000977 initiatory Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000004301 light adaptation Effects 0.000 description 1
- 230000002062 proliferating Effects 0.000 description 1
- 230000000717 retained Effects 0.000 description 1
- FAPWRFPIFSIZLT-UHFFFAOYSA-M sodium chloride Chemical compound [Na+].[Cl-] FAPWRFPIFSIZLT-UHFFFAOYSA-M 0.000 description 1
- 230000001131 transforming Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Abstract
The invention relates to a chip card for carrying out transactions in which value data representing units of monetary value or other, non-monetary entitlements is transferred between the card holder and at least one transaction partner (service provider) or is presented to the service provider for verification of such entitlements. The chip card is characterized in that it comprises a memory in which the data required for carrying out the transactions is stored, and in that it has a device for loading the card with one or more card applications (VAS applications), which in each case permit transactions to be carried out between the cardholder and one or more service providers.
Description
"CHIP CARD AND PROCESS FOR THE USE OF THE CHIP CARD"
The invention relates to a chip card, a terminal for use with a chip card and a process for using the chip card as well as the chip card system. The chip cards of the microprocessor having a payment function, e.g., electronic cash fund-ec, credit function, etc. are already in use and, depending on their nature, precodes are presented through organizations eg ZKA (Zentraler Kreditausschuß), VISA or EMV (Europay MasterCard VISA) so that they can be used as a means of payment (substitute for "cash" ). By way of example, the following can be mentioned here: ZKA, Zentraler Kreditausschuß, "interaction specification for the chip card", 27.10.1995; Europay International, "Integrated Circuit Card, Specification of Payment Systems, EMV'96", V3.0, June 30, 1996; ISO / IEC 7816-4, "Information technology - identification cards - integrated circuit (s) cards with contacts, Part 4: Inter-industry controls for exchange", 01-09-1995;
prEN 1546-1, "Identification card systems - Electronic inter-sector fund, Part 1: Definitions, concepts" and structures ", 15.03.1995, prEN 1546-2," Identification card systems - Electronic fund of interest -sector, Part 2: Security architecture ", 03.07.1995, prEN 1546-3," Identification card systems - Electronic inter-sector fund, Part 3: Data elements and exchanges ", 09.12.1994. up to the date of the chip cards can be found at: Stefan Schütt, Bert Kohlgraf: "Chip arten, Technische Merkmale, Normung, Einsatzgebiete", (Chips cards, Technical Characteristics, Standards, Fields of Employment "), R. Oldenbourg Verlag, Munich / Vienna, 1996, ISBN 3-486-23738-1. Conventional chip cards are, as a general rule, usable only for a specific object, for example, an electronic money fund or as a means of electronic identification. However, the applications applied to these chip cards as a general rule are static, that is, they are applied during the manufacture of the chip card and are kept unchanged throughout the card's life cycle.
- -
Conventional chip cards are limited both with respect to their variability as well as with respect to their functionality. In particular, conventional chip cards are set according to their manufacturing process with respect to their functionality and can no longer be changed. Correspondingly, an object of the present invention is to provide a chip card, the functionality of which is variable. A further object of the invention is to provide a chip card for which the number and nature of the application carried out by the chip card or the applications and transactions can still be variable, even after the manufacturing process. It should be possible to load additional applications onto these chip cards, and it should be possible to suppress - chip card applications and individual applications must be defined independently of one another in data and with respect to technological security to proceed or advance independently of the other . The chip card, for example, must comply with the data and technological safety conditions in accordance with ISO 7816; the individual applications of the card, however, must be independent in particular, from the same card platform.
- -
A further object of the invention is to provide a chip card with which the user himself can determine or combine or change the number and nature of the applications available on this card. Furthermore, an object of the present invention is to provide a chip card by means of which the intraservices (ie, closed circuit applications within the sense in which no registration and service transfers involving external partners have to be carried out). ) as well as interservices (ie, applications with additional external relations that involve external partners) are of course possible and can be carried out. In accordance with one aspect of the invention, an apparatus is provided by means of which one or more applications of the card can be loaded onto the card by each of which operation of the transactions between the cardholder and the cardholder is made possible. one or more service providers. By means of this load, the chip card is configured in such a way that it is provided with a new functionality, that is, it can carry out an application that was not previously open to it. The loaded data causes the applications to be defined and carried out -
along with the basic functionalities of the card such as the operating system that were not previously provided on the card. As a result, card functionality is extended or extended by this loading of an application through this specific application. In accordance with one embodiment of the invention, a data structure (DF__VAS) is provided on the chip card according to the invention which in turn is subdivided into a partial structure and a set of definition data, the identification being distinctly structure of data by means of a coding that identifies it and therefore is independent of the platform of the card. The so-called applications can now be loaded into the partial structure, that is, the functionalities or applications of the chip card. As a result, it is possible to load a specific application on the chip card. Carry out transactions between the cardholder and a specific service provider for this application. A definition data set within the data structure contains the information related to the nature and / or structure of the applications loaded in the partial structure. At least, the preference definition data set, however, the entire data structure is secured by means of at least one system key against modifications and is modifiable only by using this key. Instead of a system key, other security mechanisms can also be devised or security means by means of which modifications against security can be provided, for example, by means of a personal identity number (PIN) or other means providing service for this. security. By means of the aforementioned structure, it is possible to load a variety of applications into the partial structure and also to delete them again from the partial structure whereby the card becomes variable with respect to its functionalities or the applications that can be carried out with the same The loading and deletion of the applications continues writing the specific data of the application and the keys in the provided partial structure. Through the provision of the system key and the coding of the data structure, the structure of the data that allows the multi-functionality becomes independent of the platform of the card as such and also with respect to its self-support of the architecture security from and independently of the card platform. Depending on the applications loaded in the partial structure, it is then possible to carry out by -
means of card transactions between the cardholder and the service providers that depend on the loaded applications. Preferably, the chip card further comprises a transfer storage region in which the data to be exchanged during the operation of the transactions can be written or read from. Due to reasons that for reading the data are provided from the specific keys of the terminal of the transfer storage region, the individual accesses become independent from each other from the security point of view. The individual part structures or applications that are provided - on the preference card are mutually independent and each is assigned to a specific service provider. Represents, so to speak, the data to carry out a specific application, specific property for this service provider. Depending on the type of application and depending on the service provider, therefore, they contain different information, for example, data that represents a specific value (bonus points, account balance, etc.), information data related to the application , information data related to the service provider, etc. Preferably, however, in particular they contain keys that are specific to the application, by means of which access is made to the data of the partial structure in a way that is technically independent with respect to the security of other partial structures . The loading or generation of the partial structure or application itself, on the other hand, is protected by at least one superimposed system key. Preferably, before carrying out a transaction, a mutual authentication is carried out between the chip card and a terminal, an application, an authentication key being provided for this object, specifying the partial structure respectively. In order to carry out the transactions, the data is then written into a partial structure reserved for the specific VAS application or read from it or carried out through the transfer storage region. In the first case, application-specific keys are used in the aforementioned case, a specific application and preferably also a specific key of the terminal used, for example, is generated by means of a key that generates the key provided on the card and the specific data of the application. The data written in this way in the transfer storage can then be removed by the service provider through the terminal, which is preferably done by marking the data stored in the transfer storage as invalidated. If this involves a service provider that is not specific to the application being written, this involves conducting an inter-service call, ie the monetary data is exchanged for the benefit of or at the cost of the cardholder between the different service providers. In addition, for additional security, a PIN or password is provided to verify the right to carry out a transaction procedure. The variable structure of the card allows accommodation on the card for different periods of time from a variety of applications in a variety of numbers. The accuracy of the data withdrawn from the transfer of preference storage is ensured by the use of a signature key or by using a digital signature or at least one key. However, in this context, it is particularly advantageous if the withdrawn data remain in the transfer storage and are only marked as having been removed through the card. In this way it is still possible to obtain the information related to the transaction carried out even after - -
that the transaction has been made. In this way and by means of the insurance of the withdrawal, it becomes demonstrable that a transaction has only been carried out once. "Furthermore, it is particularly advantageous if the data written in the transfer storage is encoded with an expiration date after which it loses its value.Therefore, it becomes possible to carry out the applications which for example involve the one that becomes available. A valid ticket only during a specific period By means of a transaction counter that is preferably provided, the dates of transactions, respectively, the value data with respect to your associated transaction can be determined and positively identified. advantageous mode, the chi card according to the invention, therefore, comprises a hierarchical database concept which in its individual planes is secured by means of different keys against modifications, and at the level of applications related to the application stored in the database is variable, ensuring each individual application in relation to the res through its own specific key and being independent of the rest, and the total structure -
ensuring by means of at least one key of the system and by means of coding, identifying the structure and being independent of the same card platform. The concept of transfer storage allows the exchange of data between the cardholder as the service provider as well as between different service providers as such. Likewise, reading from and writing to the transfer storage, it is ensured by means of keys, which are also specific to the card and the application, and also specific to the terminal. An authentication carried out before each transaction as well as optionally a PIN or a password, further increases the security of the chip card according to the invention. "In the patent claims 21 to 30, a terminal is defined to be used with the chip card according to the invention.This terminal serves to load or delete applications, to carry out transactions, to view the data as well as to carry out additional functions together with the respective applications and transactions A process for carrying out transactions between the cardholder and the service provider is defined in claims 31 to 33, the data loading on the chip card of according to the invention is defined in claim 34 and 35, and the
Claim 36 defines a total system comprising a chip card and a terminal. In the following, the present invention is further described through a preferred example with reference to the accompanying drawings. It is shown in: Figure 1, diagrammatically, the chip card according to the invention, Figure 2, a schematic representation of the total system of the components of the invention, Figure 3, the data flow in the total system, Figure 4, the classes of possible operations of application through a transaction model in a schematic illustration, Figure 5, a schematic illustration of the security architecture of the chip card according to the invention, Figure 6, the data structure of a general implementation class of the VAS container, Figure 7, a variety of implementation class of the VAS container according to a working example of the present invention, Figure 8, the structure of the base of VAS container data in accordance with a working example of the present invention, - -
Figure 9, schematically, the database structure of the implementation class DF_PT, Figure 10, schematically, the database structure of the implementation class of DF_AD. Before describing the invention additionally, a number of terms used will be defined below: VAS: Value Added Services. VAS Card: The VAS card is a chip card through which it is possible to participate in the Services Added to the Value. The VAS card in addition to other applications such as e.g. Payment applications (ie, electronic money funds) contains the VAS container. VAS container: The VAS container includes structures and data, access conditions, keys and controls
(supplementary) to manage the VAS applications and for the availability of the functionality of the VAS applications. VAS application: VAS applications contain the VAS data. The access to the VAS data is controlled through the VAS application. A VAS provider carries out one or more VAS applications in the VAS container. The use of the VAS application is defined by the application, reading and processing of the VAS data. A VAS application -
it can take the form of either an intra-service or an inter-service. VAS Provider: The VAS provider is responsible for this VAS application that develops in accordance with the basic conditions of the system operator and in accordance with its own discretion and then makes it available for use by the cardholder through of the system operator and the terminals. The VAS applications will be loaded into the VAS container and the VAS card before it is possible to participate in them. Intraservice: Intraservice is a VAS application class used under the exclusive administration of the respective VAS provider. Intraservice applications are closed-loop applications implying that no accounting or operating transfers are carried out with external partners. A VAS application can be either in-service or inter-service nature. Xnte-rse-rvicios: Interservice applications are intraservice applications that through additional external connections interact with external partners. A VAS application can be of an intraservice or interservice nature.
- -
SO, operator of the system: The system operator offers the VAS providers and the holders of -the card__the VAS system to be used by them. Shipper: The card issuer or sender takes VAS cards, including VAS containers, to circulation. CH, card holder: The owner of the card or owner of the card is the person who owns the card and uses the card (in this case: VAS card) to participate in the Value Added Services. This person is not necessarily the actual owner of the card. Service terminal: The service terminal is installed by the system operator for VAS applications. At the service terminal, the cardholder can manage VAS applications on their VAS card (upload, view, delete and transfer VAS applications). The dealer's terminal: The dealer's terminal has payment functions that also offers VAS functionality. This is where the cardholder applies their VAS card so that, on the one hand, they can make the payment and on the other hand, they can participate in the VAS benefits.
- -
AID: (Application Identifier), name of applications no larger than 16 bytes for the unambiguous differentiation of applications and the selection of the application from the outside without knowledge of the database structure of a card. The AID consists of a Registered Application Provider ID (RID), 5 bytes long and optionally a Register of the Proprietary Application Identifier (PIX), not greater than 11 bytes. DF: Directory File according to ISO 7816 EF: Elemental File according to ISO 7816 Valid VAS container: The VAS container that has the ability to authenticate itself in relation to the outside world. KID: Number (Key Identifier) of a key within an elementary file containing keys
R &R: Rules and Regulations p: Maximum number of objects in implementation class DF_PT a: Maximum number of objects in implementation class of DF_AD nrjj TR- Maximum total number of objects: nrrjjR = p + a The number of records in ED_DIR is nr ^ R nrEF_TRANSFERENCE'- Number of records of the EF TRANSFER -
Figure 1 shows schematically the structure of the chip card according to the invention. In addition, of the immutable static data applied during the manufacturing process such as the master file MF and the DF_background fund function (optionally provided), an index or a data structure is further provided on the card according to the invention. or a DF__VAS database structure. This serves to accommodate additional functionalities, called VAS Value Added Services. On the basis of these additional features that represent applications that even in a later case, that is, after the card has been manufactured, they can be loaded onto the card, the card regarding its functionalities and the transactions that can be carried out. with them, is flexible and variable. The so-called VAS container (DF_VAS) that is provided in the chip card according to the invention, allows the variability and flexibility of the chip card with respect to its functions and also releases the applications accommodated in the chip card technologically with all security from the card platform, making these independent of the card platform and allowing these are still transferred to another card.
-
The new additional functionalities according to the invention (Value Added Services, VAS) are carried out through the chip cards of the microprocessor. The conversion of these additional functionalities is done through the VAS container. The VAS container on the chip card of the microprocessor is the platform to accommodate VAS applications. The VAS applications are the respective embodiments of the specific additional functionalities. In the case of payment of electronic money fund by means of the card (payment function) and the use of a VAS application (additional functionality) is carried out through separate mechanisms; In the hands of the user of the card or the card holder, however, these appear as a single procedure. The chip card of the microporcesador extends through the container of VAS that can accommodate a variety of independent applications. Makes available the functions for the application, deletion and transfer of these applications; these can only be used by the authorized system operator. The VAS container is independent of other system components in the micro-processor chip - -
from a data point and the technological security point of view. The VAS container is fully self-defined and functional by itself. An independent security architecture is defined for it so that VAS applications use independent security functions. The security architecture uses specific keys of the card that are not specific to the manufacturer and that are independent of the identification features of the card platform. The VAS container also uses a mechanism to derive specific keys from the terminal. By means of these, the VAS container itself can actively check the authenticity of the terminals, respectively the data generated by them. In the VAS container, the VAS applications are archived and through the mechanisms of the VAS container they make the data available, thus effecting the control of the associated interface points. The VAS container also allows and controls the secure interchange of data for interservices between partners. The VAS container actively takes care of the control, that is, the authenticity and uniqueness of the transferred data values. An advantage of the VAS container compared to other approaches for multi-application cards is that - -
This concept is independent of a specific card platform. It offers a security architecture that is independent of the specific security mechanisms of the platform (such as keys, identification data, PIN, signature procedures). An additional advantage of the -concept of a VAS container is that the number of different applications on the card is not rigidly predetermined by limitations and preconditions at the time of card manufacture or issuance of the card.; the current card load with applications can be freely selected by the user of the card and is restricted only by the storage capacity available on the specific card. The number of VAS applications loaded on a card at any given time depends on the actual use of the card. The user of the card individually assembles the VAS applications on his card, this also involves modifying the combination in a subsequent case. The VAS container allows a multifunctional card where card functionality during the card life cycle can be assembled and used in a variable manner and cbn with respect to the number and nature of applications. It is therefore also possible to load and use with a single card, applications for which -
they previously needed special individual cards. VAS applications can also be transferred to other cards. Therefore, VAS applications can survive beyond the life cycle of a card; they accompany the user of the card during the duration cycle of these applications. The chip card of the microprocessor with additional services is an appropriate medium for the distribution and sale of services for which there must be access for the protected data. This microprocessor chip card can be used as a means of payment, an accounting unit and for storage of securities. It can be provided with additional services and used to control them in accordance with the wishes of the client by the client himself and after the card has been issued, in a flexible manner. It also actively controls the authenticity of the participating terminals and ensures the uniqueness and authenticity of the data transferred. Figure 2 shows a system diagram.
Illustrates the components of the system. A system operator makes the system available. The VAS applications can be loaded, deleted and transferred at the service terminals (ST); the -
Additional operations are: selection, vision, interpretation, etc. of VAS applications. The providers of the VAS applications, the so-called VAS providers, design their own VAS obligations in accordance with the basic operating conditions of the system and, as far as possible, according to their own wishes. The corresponding terminal programs can subsequently be checked for authenticity by closing a digital signature. Figure 3 illustrates the flow of data in the system. VAS applications are available for use in the terminals of card users by the system operator. The VAS applications must be loaded into the VAS package of the chip card according to the invention, before their participation in it is possible. In the dealer terminal (HT) the VAS applications present in the card are used by the application or deletion of the VAS data. In order to provide the microprocessor chip card with VAS functionality, the VAS container is applied to the card's most applications -
existing ones (e.g., payment applications such as electronic money fund). The VAS container uses functions that allow the entry, deletion and transfer of VAS applications. These administrative functions are used exclusively by the system operator and are secured on the card against foreign use. The VAS container includes a transfer data storage by means of which the data exchange between the VAS applications is carried out. Two controls, TRANSFER and TAKE are used to control transfer storage. The TRANSFER command generates an entry in the transfer storage with the specific data for the respective application. In addition to the utility data, these also include entries such as the date, expiration date and identification data necessary for processing control. Through the TAKE command, the objects are removed from the transfer storage and marked as having been removed. Depending on the specific application, the objects are then marked either as remaining valid or as having been invalidated. The transferred data is checked by the VAS container with respect to authenticity and uniqueness.
- -
The VAS applications use the VAS data so that the applications are available and can be controlled. The access to the VAS data is controlled through the application of VAS using mechanisms that have been available for all the applications in the VAS container. A VAS provider operates in the VAS container, one or more of the VAS applications. The use of the VAS application is defined by entering, reading and processing the VAS data. The VAS container supports the interservices.
Interservices require access to common data, transfer of service demand and billing of services between different partners. Next, the services and applications made possible by the chip card according to the invention will be listed with reference to the examples. In each case, the description refers to the performance and function in accordance with the present state of the art. In the future, the function must be simulated by one or more of the VAS applications. First, the intraservices will be presented.
Example A: Club of clients.
A department store operates a customer club. The client becomes a member of the club in accordance with his current status receives specific club services that are not available to those who are not members. Currently, a club member identifies himself or herself in the club's environment by means of a club membership document. The club membership document is prepared when you join it, it is not transferable and as a general rule has a limited term. No specific transactions are carried out through the club membership card, that is, there is no link to the change of client. In this way, the club membership card is separated from the "modification" programs where there is a connection between the current status and the change.Analog: Wholesale vendor membership card, senator card, club card books Purpose: The club membership must be evidenced by an application in the VAS container.
Example B: Bonus system
A customer is credited for each transaction through a bonus claim. The bonus claim is accumulated and can be exchanged during the time determined by the client, for a monetary benefit. The bonus claim is valid for a defined period and can be administered anonymously or related to a person. The bonus claim arises from the change or frequency of the user. Analogue: Current status of Miles (kilometers) and More points. Object: The points account must be managed by an application of the VAS container.
Example C: Discount
The customer receives a programmed change discount. The discount is allowed for each individual transaction. The card does not manage any change history. Each transaction is single. Object: The discount entitlement will be authenticated through a VAS application.
Example D: Depending on the identity document
A person is trained through the features on the card to demonstrate to third parties their qualification for predetermined services. The -
The association of the person with the identity document must be authenticated for each transaction (photograph, PIN, biometrics). The legitimacy of the identity document is used as a security feature. Analogue: Internet access, access to domestic bank, telephone card. Purpose: The authorization must be demonstrated by a VAS application.
Example E: Value units
The units of value are bought and consumed by individual or multiple uses. For each transaction, the value is reduced by one or more units. The user's title is transferable and may be subject to limitations in terms of use. Analogue: Single trip ticket, multiple trip ticket, subscriber concert ticket, 10 point ticket, movie ticket, phone units. Purpose: The transaction must be rationalized through a VAS application.
Example F: Billing to the user - -
The use of a service is recorded in terms of time, frequency or quantity and is billed according to a fee. The degree to which the service will be called is not known in advance. Analogue: Food voucher certificate, short-term parking ticket. Purpose: Through a VAS application, billing must be allowed according to the rate. The billing data applicable to each specific case is stored in a VAS container.
Example G: Data record (mobile database)
This application allows the transfer of data from the cardholder to the VAS provider. Transactions are automated in this way that they must now proceed manually. No monetary transfer can be derived from this data. Analogue: Complementation of certificate numbers, common fund vouchers, shopping lists, cash receipts, telephone records. Purpose: A VAS provider must carry the card data in order to be able to directly provide the required service (e.g., provide a telephone connection, collect the desired purchases, electronic complementation and registration of common fund ticket numbers). The data can be stored on the card either short-term or long-term. These examples of intraservices are now going to be followed by some examples for interservices. An interservice arises when a plurality of VAS providers participate in a service. This is invariably connected to the data that leaves the environment of a VAS provider. To date, this is done through document records.
Example A: Travel cost reimbursement
A department store reimburses a customer for the travel ticket of a public transport company to travel to the department store. The customer must produce the simple travel ticket to the department store. The department store notes on the ticket that has been reimbursed. It may be that the department store in turn receives part of the refund from the carrier. Purpose: The reimbursement procedure must be carried out electronically.
- -
Example B: Travel voucher certificate
A department store reimburses the customer when making a purchase the cost for a trip to your home, issuing a certificate of proof. The customer in the ticket office receives a ticket from the public transport company or pays a lower price for the ticket. The transport company invoices the voucher certificate to the department store. Object: Simulation of the mechanisms through VAS applications that involve electronic accounting between the business and the public transport company.
Example C: Customer parking
A department store reimburses the customer for part of the parking fees when using a specific parking garage. The parking garage is operated by an independent company and receives a monetary payment for each customer credit from the department store. Object: Simulation of mechanisms through VAS applications that involve -
electronic accounting between the business and the parking garage.
Example D: Multilateral bonus program
A group of business companies and service providers contains in a joint bonus program. Purpose: Each member can credit or charge bonus points against a common account on the card. Accounting for services between partners proceeds through an underlying system.
Example E: Recognition of bonus points among service providers
Each service provider operates its own bonus program but has entered into agreements with others to recognize the points collected. Known examples are agreements between those who rent cars and airplanes to collect "miles" (kilometers). Purpose: Support the transfer of bonus points through the -card. Each VAS provider is initially to collect their points for themselves without interference from any other person. Certain mechanisms must be available for the transfer.
Example F: Night taxi
By purchasing the travel ticket of the public transport corporation, the right to travel in a collective taxi (e.g., after 10.00 pm). For accounting purposes, the taxi company must show that a travel ticket has been presented. The use of the taxi is noted on the ticket in order to avoid any abuse. Purpose: The application of the VAS is to allow the use control and accounting of this service. Next, the structure of the chip card according to the invention will be described further. More particularly, the microprocessor chip card with VAS functionality contains the VAS container. The VAS container is an application in its own right and exists either alone or even in parallel with other applications on a basic card platform. The VAS container is completely auto- 3 -
defined and functional by itself. It must be operated without the payment function usually present on the same card. In particular, an independent security architecture is defined for the VAS container so that VAS applications can use independent security functions. Parts of the Added Value Services are customer transactions carried out at the terminals of the VAS providers. The VAS provider has an interest to monitor these transactions, either for system control purposes or for collection of statistics and other data In order to optimize and unify the data structures on the card, the Use of application-specific identifications and the use of an unambiguous VAS container, ID applicable to the entire system, is recommended.This number can be used by the VAS provider to carry out the aforementioned functions and free it from the problem of managing their own numbering systems The security architecture of the VAS container uses the broad unambiguous ID system, in order to derive specific keys from the card, the use of the specific number of the card would be possible in principle, but Preference is not used because in case the VAS contain is implemented in different platforms, these can in certain cases use numbering systems The container of VAS, ID is issued by the operator of the system and is supported by the card issuer when it generates the VAS container. It is destroyed by deleting the VAS container and in this way it is removed from the system. A VAS container is considered to have been deleted and does not contain VAS applications if the VAS container ID has been removed. During a total transfer of the VAS container from an old card to a new card, the VAS container, the ID is transferred together with the VAS applications. This transfer corresponds to a removal of the VAS container from the old card to the new card. After this procedure, the old card no longer contains the VAS container. The VAS container present 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 card, a transformation of the reference numbers into the basic systems of the VAS providers is not necessary.
- -
Individual VAS applications can be transferred between two different VAS containers only under the control of the prevailing VAS provider. During this function, the association between the VAS container, the ID and the VAS application is changed which will have to be registered in the basic system of the VAS provider. The VAS container does not contain personalized features. VAS applications may contain personalized data, the extent of which however must be kept to a minimum for reasons of data protection and for improved memory utilization. The VAS applications, if necessary, must store the data related to the person in the basic system and create the association with the card through the VAS container, the ID. The support of the interservices is an important feature of the VAS container. Interservices require access to common data, transfer of service claims and accounting for services in different partners. The VAS container should make these possible and, despite-- - of this, guarantee the safety of the intraservice applications.
The 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 the application independent of any external entity. No external party can modify the VAS data without proliferating the key. For efficient operation of the interservices the partners must be able to give access to the common data. The joint access to the data is carried out through multi-step security mechanisms. The first step of joint access continues exclusively through the public transfer fields. VAS providers can exchange data through these fields without the need for mutual knowledge of the applications and keys. The terminals only require appropriate keys to input the data to the transfer fields but not for reading. Anyone can read without limitation. The data exchange can continue in both directions between the VAS provider and the partner and each has its key available to enter the data. The transfer data can be generated from an in-service VAS application from the VAS provider or vice versa, the VAS provider can support the data from the transfer field to its intraservice VAS application. The second stage is the cancellation of value units represented by the VAS data. A VAS provider introduces units of value in the VAS data by means of a special key to input the data. The units of value can be consumed by interservice partners who have available a key for unit cancellation obtained from the total responsible VAS provider. At this stage, partners who have mutually different rights interact with the non-public VAS data. - The third step is the direct data entry access to the VAS data through all participating interservice partners. This method requires an appropriate degree of confidence between the parties, because the VAS data can be modified without limitation. The transfer field serves as a connection link between the VAS applications. The data in the transfer field is generated by the VAS _ applications in the VAS container. The data can also be admitted directly into the transfer field if the person doing it does not operate the VAS application itself on the VAS container. The transfer field in principle is available for all applications, however, the entries can only be made by the person entitled to this (with a key). Only the recipients who are entitled to this in terms of the regulations, that is, the Rules and Regulations. R & R can remove the data from the transfer field. The receiver checks the presence of the transfer data directed to it and withdraws these for processing in its own system. In order to prevent the manipulation of the transfer data in a public exchange, the generator introduces a particularity of authenticity and the VAS container introduces a sequence number. The uniqueness of a transfer report is ensured by these elements and the origin of the data is demonstrated. In case of need, the transfer data receiver is supplied by the generator with the means to carry out an authenticity check. If this is not desired, the acceptance of the data can be carried out in good faith; in that case, the particularity of authenticity can possibly only be checked when the accounting is carried out in the basic system of the VAS provider that generates the same. The withdrawal of data from the transfer field is possible only once without loss of the particularity of authenticity. During the retreat, the 3
Data is marked and remains (as a copy) in the transfer field. This allows the test of the transfer procedure after the withdrawal of the data, during a certain period. The data in the transfer field has an expiration date. The expired date can be overwritten when required by arbitrary applications. The data in the transfer field can be marked in the withdrawal in order to be released for immediate overwriting. In case the transfer storage is completely filled before the expiration of a transfer data set, the cardholder must delete the entries that are no longer necessary in the service terminal. For the modeling of VAS applications, 3 operations are defined. These operations act on the VAS data. Loading and deleting applications are fuons of the VAS container and are not taken into account in the following paragraphs. Purchases: In general, the purchase of the title to the services and the presentation of proof thereof in the VAS data of a VAS application. Cancellation: Generally the redemption of the title "without or with full or partial consumption of - -
VAS data of an application. The procedure generates an electronic receipt that is filed in the transfer field. This receipt has an appropriate expiration date by which it can be deleted from the transfer storage. Withdrawal: Usually recovery of electronic receipt from a transfer field for further processing (eg basic 10 system). A copy of the receipt remains and serves as proof of "cancellation". The "Acquisition" of the VAS data can only proceed through the respective VAS provider. The "cancellation" of the VAS data can be carried out
only through the VAS provider who generated this through their "purchase" or through an interservice partner
< • authorized for this through the VAS provider. The "withdrawal" can also be carried out by any VAS provider. An interservice without equal rights of
access of the VAS data causes the action of a "withdrawal" of current state transition by the partner. The electronic receipt in this recovered form can then be asserted through the system operator and the basic system of the VAS provider. The "purchase" and the
"cancellation" can be carried out in one step.
- -
VAS applications with common characteristics can be subdivided into classes. These classes form the basis for the data structures in the VAS container. The VAS provider during the implementation of this application selects an application class.In this context, the following application classes are defined: • Points database • Ticket • Identification document • Proof certificate • Database The base Point data represents an application class in which a point value account is managed.To and from the points of account values can be credited and withdrawn.The credit is values continuously through the VAS provider since the base The new account balance has been admitted to the database, and the debit of the securities advances through the "cancellation" operation in the context of which an electronic receipt is stored in the transfer storage, as evidence. Two fuons is carried out by two different access keys.
- -
The ticket represents an application class in which there is a value field that can be canceled and thus be consumed once or several times. The securities credit on the application class ticket is carried out only once. The identity document represents an application class in which the VAS data receives evidence of an intitulation. Evidence is usually canceled through use; however, after predetermined criteria, v. gr., after a lapse of time, it is invalidated. Depending on the definition of the application, the authenticity of the identity document (eg, nearby parking permit) or the document presentation act is documented (eg collective taxi trip using a monthly ticket: Generation of an electronic receipt through the card. The receipt is submitted by the taxi company to the public transport corporation and is reported for pro rata). Optionally, the use of the identity document can be documented in the transfer storage of the card, through electronic receipts. The - voucher certificate represents an application class by means of which the service entitlement (as a general rule for short duration) is placed in the interim storage of the card. These - -
Certificates vouchers are stored exclusively in the transfer storage of the VAS container. The application that uses the certificate certificate as a general rule is different from the generation application. The withdrawal of the certificate of proof of transfer storage is possible once only and is documented by means of the card. A particularity generated by the VAS container can be used during accounting in the basic system. Data memory represents an application class in which the VAS provider stores the data in a VAS container to provide an additional service for the customer (eg, the last menu in a fast food restaurant, last number of the numbers of common funds, service preferences, proposition lists). This data is for information only and does not represent a claim for services against the VAS provider. Access to the data is controlled by the VAS provider. Each application class is characterized by a typical user cycle. The following table illustrates the frequency at which the three operations previously defined apply to the VAS data of the application class (Please note: "Purchase" does not mean - -
"load application" and "removal" does not mean "suppression application").
Table 1 - User Cycle
Ticket Base Document Certificate Memory Data of _ Proof of Identity Points Data
Purchase Multiple Simple Single Simple Multiple *** Cancellation Multiple Multiple Multiple Simple Never
Simple Multiple Multiple Removal Simple
*** In the "data memory" application class, no intitulation is acquired, the application only inputs the data in the application. Figure 4 illustrates the application classes and operations mentioned above through a transaction model. Next, the security architecture of the chip card according to the invention will be further treated. In order to ensure safety, the following keys are defined.
Table 2 - List of Keys
Name Site Fork Description
K SO Key Operator Container to manage the VAS Container System of VAS
R • AUT Key Operator Container for authentication of the VAS container system of VAS
KSIG VASC Key Operator Container to encode the VAS transaction data system
KGKDEC Key Operator Container for the derivation of VAS system from KGKDEDí p ??
^ -LVASP Key Provider Application for VAS VAS Access Write to VAS Data
KRVASP Key Provider application for VAS VAS access reading to VAS data
KGRDEC x Key Supplier Provider for the derivation of VAS VAS K DEC
DEC Terminal Provider Key for Authentication of the VAS Terminal of Negotiating Dealer
-
The security architecture is based on the life cycle of the VAS container or the VAS applications and is stratified according to the responsibility of the cases involved. A schematic illustration of explanation is evident from Figure 5. In the following, some elucidations of the structure of the VAS containers as well as the applications applied thereto are provided. The VAS container as well as the VAS-specific supplementary controls are applied either to the card by the sender along with other non-VAS applications or at the latest they are integrated into a service terminal by the authorized VAS provider to the platform of the existing card in a service terminal. For the second possibility, the following mechanism can find application: The operator of the system agrees with the sender on a temporary key Kgo * • The sender opens the card with its key that is only known to him, establishes the VAS container files and in particular, write the 0 * in the DF_VAS. The operator of the system can then in the latter case (e.g., the card comes into contact with a service terminal for the first time) replace the Kgo * key by means of its "own Kgo key which is only known by it.
Operator of the system can now by itself give input to the data, such as for example, KGKGJEC ° can in the case of a platform with dynamic memory management generate or delete the files for VAS applications. Therefore, it is ensured that the shipper after the first use of a VAS card no longer has access to the VAS container and that the system operator only has access to the VAS container. Due to the absence of any of any of the common data structures and data exchange with other applications, the security architecture of the VAS container is therefore independent of other applications present on the card platform. In a special embodiment of the invention, however, use is made of the first possibility: The shipper is required in accordance with the instructions of the operator of the system that applies the VAS container including all keys to the VAS cards. The VAS container consists of a predetermined data structure, predetermined access conditions (Acs) and certain global data. The global data contains inter alia the Kgo key to load or delete VAS applications. It is ensured by this key, known only to the system operator that only VAS applications can be loaded. For this purpose, the -
card requires external authentication by the operator of the system through K o- When a cardholder wishes to load a VAS application into a service terminal, the applicable VAS provider instructs the system operator accordingly to do this for your own benefit When the VAS application is loaded into the VAS container, the VAS provider transfers the KL ASP and KRVASP keys to the system operator who then supports these in the application. The ^ -J _,? JASP key allows the VAS provider to protect the application data against written access and additional internal data against read access. For this purpose the card requires an external authentication of the VAS provider based on KLVAgp, that is, the card actively checks the authenticity of the terminal. After having satisfactorily performed this function, a terminal is allowed to have written access to a VAS application and read access to the internal VAS data of the application. An internal authentication, that is, verification of the application of VAS (and thus the card) in terms of authenticity, through the terminal of the dealer, can be carried out optionally. When the VAS application is used by the card holder, this internal VAS data - -
can be written in the application or can be modified in optional terminals that have access to the KLVASP key- The "purchase" function is supported by an UPDATE REGISTRATION command that must be preceded by an external authentication by means of the KLVA key p . Read access for all non-internal data of the VAS application is only allowed if a previous external authentication has been carried out by means of RRVASP O via Ko or through the correct entry of a PIN or password using the system operator . Password protected access / PIN is provided in order to allow the cardholder to inspect the data in the terminal or in the wallet. The cardholder can choose in a service terminal to activate or deactivate the PIN / password protection by reading the value or the current status data. The global data of the VAS container is associated with a key KgjQ_v SC To sign the data extracted from the transfer field. Through the signature, the integrity of these transaction data can be checked when they have to be transferred protected against manipulation between the inter-service partners for mutual accounting. In addition to a signature optionally introduced through the interservice partners, a signature based on Kgjg vASC and a counter of - -
transaction managed by the VAS container for the data sets issued by the card through the "withdrawal" operation. Because on the one hand the reading of the transfer field is allowed by any, but on the other hand the signature of the card through KgIG VASC can be generated only when a call is made for the operation of "withdrawal" (and this can happen only once), any double accounting that is not allowed for voucher certificates is recognized. Each interservice partner is able to have the authenticity and uniqueness of a proof of retirement certificate verified by the system operator. In addition, the authenticity of the VAS container can be verified by checking the signature by the system operator. In the event that a card platform employs asymmetric key procedures, it is also possible to use a private (secret) key within the card as a K j VASC for signature purposes or to derive this key from a private Key Generation Key. In this case, VAS providers can use public (non-secret) keys for themselves by checking the signature without having to consult the system operator. Part of the VAS container data is formed by a global Key Generator Key KQ ^ EQ, which has the ability to generate the Kpjgc access key for -
all terminals of all VAS providers for the authority check for the "cancellation" operation (the key derivation of the objects and the check will be discussed again below). The cancellation of monetary value data is not subject to the same security measures as loading or purchasing a title. For this object it is sufficient to use a global key instead of a specific key for the application. The global key is initially converted by derivation into an application key and then by renewed derivation on a terminal key. The VAS provider is only informed of the specific derivation of the global key application by generating the own terminal key. This is briefly described below: We present as mac (k, d) the calculation of a message authentication code for a message d and a DES k key by means of DES. As long as the message is not longer than 8 bytes, it corresponds to the encoding as (presumption ICV = 0). Represent as macp (k, d) the mac computation (k, d) with subsequent adaptation of the parity bits. The result of k '= macp (k, d) again is a valid DES key. The calculation of the terminal key specifies application then proceeds as follows: - -
Each card stores a key
KGKDEC '
which is the same for all cards and which is kept secret by the system operator. The operator of the system provides the means for this key to be personalized on the card. From this key, and all other keys of the VAS application terminal can be derived A VAS provider wants to introduce VAS application with AIDA = RIDVAS • Pl ^ A- The system operator now calculates the KGKQEO and PIX key application spec
KGKDEC / PIX = macp (KGKDEC, PIXA)
and deliver this key through the VAS provider. This VAS provider, through its terminal ID, derives from KGKGJEC PIX. For all the terminals of the TRANSFER command, it is assumed that it applies to VAS application A, its specific keys:
KDEC = mac -KGKDEC PIX 'Terminal ID) = macp (macp (KGK).}. Gc, PIX ^), Terminal ID) -
The VAS provider stores these keys in its terminals. In case the VAS provider does not operate the terminals itself, it generates the keys and distributes them to the terminal operators. 4. The VAS card only carries out the TRANSFER command if the command comprises a cryptogram C generated by the terminal that is formed through the data of the specific data of the message in the transfer storage. The card itself recognizes KGKGJEC and obtains from a terminal in addition to the data of the user data and the cryptogram C, the terminal ID as well as PIX (or alternatively the same card knows the PIX, for which the description of the TRANSFER command can also be seen). The card is now able to calculate C cryptogram through the user's data: mac (macp (KGK ^ EO, PIX), Terminal ID), data = = mac (macp (KGK) 3EC pi? / Terminal ID), data) = = mac (KI EO, data) = = C * The card now compares the cryptogram C calculated by itself with the cryptogram C calculated by the terminal. If they differ, a transaction termination of a failure report is carried out. In case of congruence, the VAS card will execute the TRANSFER command. The different security measures are aligned with the different constructions of the service terminals or the dealer terminals (for loading or purchase respectively) and the simple dealer terminals (for cancellation). In order to carry out the "cancellation" operation a terminal must authenticate itself with respect to the card having knowledge of a K ^ EC- If that key K ^ EC is compromised, the aggressor can only carry out the function of this simple terminal. However, this procedure is recorded on the card. The documentation contains a non-ambiguous sequence number, cancellation and terminal ID. VAS applications use VAS container security services to regularize access to VAS data. The execution of specific VAS functions is limited to authorized parties by defining the access rights. In general, it is necessary that each of the publicly accessible data regions of the VAS application (e.g., to read the values by means of a portfolio) and private data regions of the responsible VAS provider be made available, the latter of which can -
protect against access through third parties (e.g., internal administrative data). Taking into account the fact that according to ISO 7816-4 the cards do not provide differentiated access protection for the Individual Records of the Elemental Files (EF), it is necessary to use a plurality of files each containing a record to present different views about a VAS application. Therefore, the storing of the application class points, ticket, identification document and differential access protection data memory can be performed by subdividing the VAS data into four Elemental Files as illustrated in Figure 6. The four Files Elementals contain the following data or are protected as follows:
- -
Table 3 - Summary of Files
Cam or Contents Typical Use Access Protection
EF_TECLA Contains the key A KLVASP provider 'KRVASP VAS must be known if it is available to the same provider through KLVASP's VAS (note: before each application is stopped that VAS escalation and optionally screens the data from VAS in for each card, EF_INFO the provider of EF_INTERNO and VAS provides EF_VA? R, resun only pair of keys) before it allows it to be the data of EF-INTEKNO. A terminal must authenticate itself by means of KRyAgp before being allowed to be the VAS data of EF_INFO, EF VALUE
EF INFO No informationInformation The content of these internal information to ticket data units only through the information can be written to me application of the program by the VAS provider of bonus VAS (authentication ternation by means of knowledge).
Information on KLVASp). Documentation should only be possible in the termiidentities that have information access to KRVASp or Kso, the ticket or if the holder of the card station gives entry to a correct PIN naming. (The pro-
Field Contents Typical Use Access Protection
PIN protection can be deactivated by the card holder)
INTERNAL EF the counters data The content of these internal of the inmates, data units can application of states of only be written and read VAS account, by means of the information provider of VAS. The tax protection, access code is based on additional external authentication keys by means of: knowledge of • KLVASP bonus programs • discount scales • hidden identification features • EF codes VALUE Units of This unit of Only the supplier value of the data contains of VAS can write application of values responestos explicit data sables uñate mind (authentication external application by co-provider of knowledge of R LAVASP VAS. Implicitly the value can be reduced • Status of using the account command "cancel" by a partner • Ticket of who is authorized to carry out the function public through the pro se value of VAS (through residual signature of the operation • Credit that is canceled with • Accountant of the R DEC) User Reading agreed) or with EF INFO.
This structure of Elementary Files (EF) supports the same different access rights for all application classes. Taking into account that the application classes are now combined into a single implementation class that provides the number and size of the Elemental Files, the waste of the storage capacity can be minimized due to different space requirements for the applications. In storage of application classes and the ticket they require the same resources of EF_TECLA, EF_INFO, EF_INTERNO, EF_VALOR and therefore they are combined in an implementation class "DF_PT". For the application classes, the identity document and the memory of the Element Files EF_TECLA and EF_INFO are sufficient and therefore they are combined in the implementation class "DF_AD". Considered in terms of numbers: There are p objects of the implementation class DF_PT and objects a of the implementation class DF_AD in the VAS applications of point storage of application classes and ticket, and the document of identification and storage of data can be loaded respectively. Specifically for the voucher certificate of the application class, which must provide public reading access for all VAS participants for joint data exchange purposes, the implementation class transfer field is used. Write access is possible only indirectly through the application of the TRANSFER command that presupposes a correct K ^ EC economic signature. This implementation class consists exactly of an entry in the Element File EF_TRANFERENCE that belongs to the global data of the VAS container. The objects of this class are records in this file. We also refer to this kind of implementation as "EF_TRANFERENCE". The implementation classes illustrated in Figure 7 exist within the VAS containment. These implementation classes form the storage model of the VAS container. The storage model can be available in two ways. Nature depends on the card platform: Fixed division of the storage region for the VAS containment: For the implementation classes DF_PT and DF_AD a maximum number is set poa according to the case, of objects by the sender and is loaded by issuing on the card using ARCHIVE CREATE commands. The objects are represented as DF_PT and DF__AD -
respectively. VAS applications can be subsequently loaded into free objects, that is, not occupied by other VAS applications. To load or delete the VAS applications, only then are the RECORDING UPDATE commands necessary. In this way the user sets the number of possible objects of the two classes is implemented according to their own requirements; however, these may differ from the current VAS user pattern of the cardholder. The subdivision is maintained throughout the card's duration cycle. A VAS application is loaded into an object that belongs to an appropriate implementation class. In this way, for example, a VAS application that represents an identity document can also be accommodated in an object of the implementation class DF_PT, if there are not (more) objects of implementation class DF__AD available. The assignment of a VAS application to an object is carried out by admitting a tripel (PIX of the VAS application, FID of the loaded object, clearing the name of the application text) to the global database EF_DIR of the VAS container . The removal of the application corresponds to the removal of this tripel from EF_DIR and the destructive reading (using the UPDATE LOG commands) of the memory loaded with the application.
- -
This modification is used with card platforms that do not support the dynamic generation or suppression of DF / EF structures. Dynamic establishment of objects of the implementation class: For each VAS application to be loaded, the files are established using the ARCHIVE CREATE commands as required for the underlying implementation class. When the VAS application is deleted, the DF / EF occupied by it is removed entirely from the card _ and the storage space is free. The maximum number of objects of the implementation classes is not explicitly determined here by the shipper and depends only on the storage capacity of the available card. This modification presupposes a dynamic database administration by the card operating system. In the next working example we will start from the first modification because the second one makes higher demands on the available card platform. However, if dynamic memory management is available and it has been ensured that greater storage capacity can be saved through the dynamic establishment of objects of which corresponds to -
administration costs, then the existing concept can be adopted and offers more flexibility to the cardholder. The following are the data structures and controls by means of which the VAS container and the functionality of the VAS client card can be implemented when compared to other components of the system. In addition, VAS operations are placed for typical business situations that describe the respective interaction between the VAS container and the terminal.
The following preconditions apply to the implementation:
Each card, independent of the platform, makes it available for the dealer's terminal in the same data and command interface. Accordingly, the required commands are clearly described in their coding. The service terminals are able to recognize the platform of the card. The functionality can therefore be achieved through specific controls on the platform. Correspondingly, these transactions are partially written informally. The manner in which this function is provided is left to the card manufacturer. In Figure 7, a variety of implementation classes of the VAS container is illustrated schematically in this context. Figure 8 schematically shows the data structure of the VAS container. Figure 9 schematically shows the data structure of the implementation class DF_PT, Figure 10 shows the data structure of the implementation class DF_AD. Access to the VAS container files is explicitly restricted by the following access conditions (AC):
- -
Table 4 - Access Conditions
Database Admin Access Reading Access Writing
DF_VAS? So NEV NEV
EF_ID? So ALW? So EF_DIR? So ALW? So Global KEYS? So NEV? So PIN? So NEV? So EF_VERSION? So ALW KSO
EF_SEQ? So ALW KSO
EF_TRANSFER? So ALW KSO
DF_X Kg0 NEV NEV (X = PT ?, ..., PTD, AD1, ... ADa)
EF_TECLA? So NEV KSO
EF_INFO? So PIN or KRVASP KLVASP 0 KS0 EF__INTERNO? So KLVASP KLVASP
EF_VALOR? So PIN or KRVASP KLVASP Kg0 -
In this context, CAs have the following meaning
• ALW (Always) = The command access to the database is always allowed. • NEV (Never) = the command access to the database is never allowed. • KS0 = Prior to access, the external authentication of the system operator must be carried out using the K Q key. • LA? Agp = Before accessing, the external authentication of the VAS provider must be carried out using the KLVASP key. . • R? A p = Before access, external authentication of a terminal authorized by the VAS provider must be carried out using the Kp Agp key. • PIN = Before accessing, the correct PIN must be accepted by the card holder and the card must be clearly transmitted by means of the VERIFY command. • PIN or R? A po Kgo = Before access either the correct PIN must be accepted by the card holder or external authentication carried out by the VAS provider using Kp? Agp or by the system operator using K or "In this context it should be noted that the link Or of the access rights as represented above, in the card operating system, is not provided as a general rule. When applied, this could involve special implementation costs (alternative: special READ command with implicitly set security attribute). The data fields within the records of the Elementary Files are differentiated according to the following formats: ASCII, Binary, BCD, Date, Format Chain. Data elements of the type "format string" contain the VAS data in packaged presentation that can be presented to the cardholder in the terminal. For optimum data storage utilization, clear the text and the binary data is mixed and is able to be presented through the macro format. All the Elemental Files (EF) of the VAS container are defined in accordance with ISO 7816-4 as EF data bases prepared in linear format with constant length records (linear fixed log files). The EF_ID Elemental File of the DF_VAS consists of a record that contains the VAS container, the ID. The EF_DIR Elementary File of the DF_VAS consists of the records nr ^ iR. For each application of -
VAS loaded in the VAS container, its extension of the owner identifier (PIX) and its physical storage site (FID of the DF_X where the application has been loaded) is set in a record of the EF_DIR. The PIX identifies, e.g., as a code number, the application and the service provider to which the application has been assigned. The inputs in EF_DIR are dynamically established in the operator terminal of the system operator. Records without the entry are set with an empty TLV object '61'. When a VAS application is loaded, a free storage region is searched for the appropriate implementation class, certain VAS data is admitted to it, and finally a new record is generated in
EF_DIR When an application is deleted, an empty TLV object must be written correspondingly in the EF_DIR. The EF_VERSION Elemental File of DF_VAS consists of a record that contains a version number of the VAS container. The version number can be used by the terminal in order to differentiate between the modifications of the -
Different VAS container and / or different software versions. The Elemental File EF_SEQ of the DF-VAS consists of a record that contains the number of the next entry in the transfer field. The sequence number is read by the TRANFERENCE supplementary command. This command then generates in the transfer field EF_TRANSFERENCE a register in which inter alia the sequence number EF_SEQ is transferred. Together with the command of TOMAR which ensures that each record of the transfer field is withdrawn only once and that this withdrawal is recorded by the signature through the sequence number, you can make sure that you withdraw only once from certificates (originals) or receipts. Then, the transfer storage can be treated in greater detail. Transfer storage is established within the VAS container and comprises the records of nrEF_TRANSFERENCIA. The entries in the registers of these files contain transfer data generated by the TRANSFER command. The data exchanged between the VAS applications as well as the storage of the VAS data from the Class Checker Certificate is carried out through the transfer storage.
The storage of TRANFERENCE can be read without restrictions, however, the write access is only possible through the specific command of VAS, TRANSFER and TAKE. The loading of the data fields by means of the TRANSFER command proceeds by means of an algorithm 'last used recently' on the card. The oldest record in the database can be determined by looking for the lowest value in the first two bytes of the record. The data fields can be marked by the "TAKE" command in the transfer storage as it is removed and / or removed. In each case the deletion of the data in the transfer storage is carried out by overwriting with new data. Each record in the transfer storage contains, for example, an expiration date, the terminal-ID, the PIX, the sequence number and optionally additional data. Each EF__INFO Elemental File within the DF_X lists (where X = PT ^, ..., Ptp, AD] _, ..., Ada) comprises a record containing the expiration date as well as the general VAS data of an application of VAS. For example, the nature of the ticket (single or multiple ticket) or the locality can be given here. The EF INFO, however, must contain at least one name - -
Clear text of the application that can be read from the operation of viewing the VAS applications. Sensitive data must first be protected by the VAS provider using appropriate external key algorithms. This EF is able to be read if external authentication is carried out with K o or KR? Agp or where the card holder in the case of an activated PIN protection gives access to a correct PIN. Each EF_INTERNAL Elemental File within the DF_X records (where X = PT] _, ..., PTp, AD] _, ..., ADa) consists of a record that may contain internal VAS data from the related VAS provider with its loaded VAS application. Neither the cardholder nor any other VAS provider can read this internal data. Each Element File EF_VALOR within the registers of DF_X (where X = PT_, ..., PTp, ADX, ..., ADa) comprises a register that can contain an integral value field of the VAS data. This EF can be read if external authentication is performed with K o or KRVASP or if the card holder in case of activated PIN protection gives input to a correct PIN or a correct password.
- ¬
The next one will start with a pure DES-encoding. That is, all keys in the VAS container are DES keys and are encoded in 8 bytes (including parity bits). Within the VAS container and within the VAS applications, the following keys can be referenced which are referred to by their KID (Key Identifier):
Table 5 - VAS Container keys
KID KEY
So 00
KAUT 01
KSIG VASC 02
KGKDEC 03
Each key is coupled with a faulty operation counter. This records failed authentication attempts with this key and blocks a use - -
additional once an admitted limit has been reached for this counter. Within the VAS application, the following keys can be referred to by their KID.
Table 6 - VAS Application Keys
KID KEY
KLVASP 04
KRVASP 05
Each key is connected with a faulty oepration counter. This records failed authentication attempts with this key and blocks any additional use once a supported limit for this counter has been reached. The VAS container contains a personal identification number or password (PIN). This is used to identify the cardholder through the VERIFY command. The PIN is connected to a faulty counter that registers each false entry and blocks a PIN comparison when a limit is reached.
- -
This block can be returned by the system operator using appropriate management commands. The defective operation counter is returned once the correct PIN has been accepted. The following parameters exist for the VAS counter that can be selected by the card issuer according to the space available on a card platform and their individual wishes: • p number Maximum of objects of the implementation class of DF_PT = maximum number of VAS applications of Application Class Points and Ticket Storage that can be loaded simultaneously into a VAS container; • A maximum number of objects of the implementation class DF_AD = maximum number of VAS applications of the Identity Document of the application classes and the Data Storage that can be loaded simultaneously in a VAS container; • nrDIR Total number of objects Maximum: nrpjiR = p + a The number of records in EF_DIR is nrpjiR • nrEF_TRANSFERENCE number of EF records TRANSFER -The storage requirements for the data of the described Elementary Files is as follows: Bytes
Global Data from EF_ID 4 VAS Container: EF_DIR 9 * (p + a) EF_VERSION 1 EF_SEC 2 Global Keys, Pin 64 + 2 Transfer Field: E F_TRANSFER 48 * nrEp TRANSFER
Property Data EF_TECLA (p + a) * 32 of the VAS Provider- EF__INFOR (P + a) * 62 EF_INTERNO p * 10 EF VALUE p * 3
If we select, e.g., for parameters p, a and nrEF TRANSFER the following values, then the following minimum storage requirements for the VAS container are raised (without storage requirement for supplementary commands):
- -
Parameter Storage requirements p = 8, a = 3, nrEF TRANSFER = 15 2030 bytes p = 10, a = 5, nrEF TRANSFER = 20 2758 bytes
The maximum storage requirement is probably higher than the minimum storage requirement by approximately 10 percent. In the following, the commands of the chip card according to the invention will be discussed in greater detail. The READING REGISTER command is used to read the data of the Elementary Files linearly. The card in your response supplies the contents of the records. The _EF is referred to by the
Short File Identifier (SFI). The current status code '9000' indicates a satisfactory functioning of the command; Any different code is considered as an error. The UPDATE REGISTER command is used to support the data in the registers of a linear EF. The command message contains the reference to EF, the register and the data. The response of the card contains the current status code. The current status code '9000' signals the successful conclusion of the command. Other current status codes indicate an error. The command of the CHALLENGE CHALLENGE requires a random number from the card. The random number is used in conjunction with dynamic authentication in EXTERNAL AUTHENTICATION. The response message of the card contains a random number, 8 bytes long, and the current status code. The current status code '9000' indicates the successful operation of the command. Any of the different current status codes indicate an error. The EXTERNAL AUTHENTICATION command allows the authentication of a terminal against the card. EXTERNAL AUTHENTICATION is used with the context of the VAS applications for authentication of the system operator and the VAS provider. The EXTERNAL AUTHENTICATION transfers a cryptogram to the card that before this has been generated by the terminal by means of encoding a random number. The card compares the cryptogram with a reference value that was calculated using the same procedure. If both values are equal, the card notes internally that the access condition authentication for this key has been performed. If the comparison turns out to be negative, the card will issue the current "unauthorized" status and decrease a counter of -
internal defective operation. Once this counter reaches the value of 0, any additional operation of the EXTERNAL AUTHENTICATION is blocked with the current state "authentication blocked". The response message on the card contains the current status code. The successful operation of the command and the authentication of the terminal in relation to the card is indicated by the current status code '9000'. Any different current status codes indicate an error. The INTERNAL AUTHENTICATION command is used to check the authenticity of the VAS container using a terminal. The card for this object calculates a cryptogram through the reference data derived from the terminal. The terminal in turn forms the cryptogram and compares them with the value of the card. In case of equality, the terminal can adopt the authenticity of the VAS container. The response of the card contains the cryptogram and the current status code for the execution of the command. The successful execution of the command is indicated by the current status code '9000'. Any of the different current status codes indicate an error. The VERIFY command is used to verify the PIN of the cardholder. The command transfers to the data of - -
Uncoded PIN to the card where a comparison with a stored reference value is carried out. If the admitted value and the stored value are identical, it is considered that the "PIN" access conditions are met. The response message on the card contains the current status code. The current status code '9000' indicates a successful execution of the command. Other current status codes indicate an error. The TRANSFER command generates an entry in the transfer storage. Three modes of operation are defined for control: 1. Generation of an entry in the transfer field by reducing values in the EF_VALOR field of the application of the Class Ticket or Point Storage. 2. Generation of an entry in the transfer field by creating a receipt in the application of the Identity Document class. 3. Generation of an entry in the transfer field generating a certificate or voucher in applications of the Certificate of Class Certification. The operating mode is automatically selected by the card: If the command is executed within a selected application-DF, the presence of an EF-VALUE is checked first. If the EF-VALUE is present, the card executes the command in mode 1, alternatively in mode 2. If a DF application has not been selected within the VAS container, mode 3 is used. The terminal, when requested a TRANSFER command, provides the card with the following data: • Current date • Expiry date for the entry in the transfer field • Identification for the terminal that generates this entry • User data for the transfer field • PIX of the VAS application (mode 3 only) • Number of units to be subtracted (mode 1 only) • MAC related to the aforementioned data, sequence number and VAS container number. The card, once the TRANSFER command has been called, carries out the following sequence: 1. Search for a free entry in the transfer storage. (The following list provides in reverse order the priority in which the entries - -
existing ones are going to be overwritten: "Entry marked as removed", "entry marked as withdrawal" and "expiration date reached", "date of expiry reached". 2, Set the PIX to the terminal data in modes 1 and 2 3. Set the sequence number to the data in step 2. 4, Set the VAS ID container to the data in step 3.
, Derive the KGKQEC PIX encoding the PIX under KGKJJEC *
Derive the KGJEC by coding the terminal ID under KGKDEc, PIX-. 7. Generate the MAC through the data of step 4. MAC comparison of step 7 with MAC of the terminal. If the values are different, the card interrupts the function and reduces the faulty operation counter for KGKDEc For mode 1: Test the value field EF_VALOR in the register where the application was loaded. If there are insufficient units present in this field, the card interrupts the function at this point. Otherwise, the value in the application is reduced by this amount. 10. Assembling the command message. 11. Increase the content of EF_SEQ by 1. The command message contains, for example fields that include the expiration date, the terminal ID, the - -
transaction data, a field for the operation mode (contains, e.g., in mode 3, the PIX), as well as a cryptogram. The cryptogram is calculated using the KGJEC key the data formed through MAC, for example, covering the transaction data and the terminal-ID. The response message of the TRANSFER command includes, when satisfactory, a data field of 8 bytes long and the current status code '9000' which is 2 bytes long. It is response to messages with a current status code that differs from '9000' are interpreted as error codes. The data field of the response message contains an error free situation, (that is, in particular the cryptogram of the command message was correct) the cryptogram encoded with KQEC of the command message. In this way (instead of an internal authentication using Kau ^) an authentication is carried out implicitly through the VAS container. The TOMAR command is used to remove objects from the EF_TRANSFER implementation class. Technically, the execution of the command TOMAR means the reading of a record that is going to be represented from the storage EF_TRANFERENCIA, being retained the record in the storage during a term as long as the -
it requires storage space for a new entry, the data set being marked as withdrawn.
Technically considered, anyone can use the command to TAKE in order to remove a set of data, however, according to R & R only, a VAS provider for which the data set was intended, must do this. For the removal procedure, the following may be assumed. The VAS provider that wants to remove a certificate or voucher, looks for the transfer storage for an appropriate data set (e.g., through the SEARCH command or by explicitly reading each record). The data set in any case will be read and its content can be checked. A presentation of the data game in response is therefore not necessary. In addition it can be assumed that the registration number is known. The TOMAR command provides the following modes: • Removal with simultaneous annotation that the data has been invalidated. • Removal without the aforementioned annotation. The data remains valid. The command message contains fields with the terminal-ID, PIX of the application and a random number generated by the terminal.
The PIX on the remote represents the application that removes the data. It can differ from the PIX of the data set that is being removed. It serves exclusively for the KQEC derivation of the terminal of the merchant who performs the removal. The response message of the card contains a cryptogram Cl with gjQ_? Ago which is related to the data of the records of the transfer field reported in the command message and the VAS container, the ID, a C cryptogram with KG > EC of the terminal performing the removal through C] _ and the random number taken from the command message. The response message also contains the current status code. The KQEC key is derived as described above as well. Authenticity is implicitly demonstrated by the VAS container due to the cryptogram via KGJEC- The Authenticity Test and the singularity is calculated by cryptogram C
(since C is formed through the sequence number, the removal bit of the transfer field record and the VAS-ID container) that can be verified by the system operator. The current status code '9000' indicates the successful execution of the command. The different current status codes are interpreted as errors.
- -
It must be assumed that SO requests an AID? g in accordance with IDO / IEC 7816-5. More specifically: Request a RID? Ag, 5 bytes long for the VAS system. The AIDVAS of the DF_VAS list should be read as follows: AID? Ag = RID? A. PIXJ ^ F VAS- For each VAS A application, a 3-byte long PixA is issued in accordance with R &R in order to unambiguously identify the first one within the VAS container via AID = RID? Ag.PIXA. After the DF_VAS selection, a view in which a VAS application A is contained can be selected using the selection file SELECT FILE < PIXA > . The UPDATE KEY (KID, K) represents a command that depends on the platform of the card whereby the key is replaced by a new K value using the ID Key Identifier. Before a VAS application outside of one of the implementation classes DF_PT or DF_AD (corresponding to the application classes of Point Storage, Ticket, Identification Document or Database) can be used by the cardholder in the dealer's terminal, must be loaded -in the VAS container at a service terminal of the appropriate VAS provider. In principle it is also possible that a - - -
The card issuer receives instructions through the VAS provider and an OS loads one or more of the VAS applications into the VAS container already when the VAS container is installed. This loading process constitutes a special case of what is described here. The procedure of loading a VAS application: 1. The cardholder inserts a VAS card into a service terminal. 2. The service terminal checks that a VAS container is present: • SELECT THE FILE <; AIDVAS > (Error report if the VAS container is not selectable) • READ THE REGISTRATION < SFI of EF_ID, 0 > (presentation of the VAS content number). Optionally, the validity of the VAS container is checked. For this, the service terminal requires internal authentication of the VAS container: • INTERNAL AUTHENTICATION < random number, KID for KAUT > The service terminal checks the response and in case of an error (with error presentation) terminates the procedure. 3. The service terminal offers the card holder a selection of several options. One of them reads the VAS request. This is selected by the card holder. All VAS applications that can be loaded into the service terminal are now presented to the cardholder, a selection is expected. For this object, the operation of viewing the VAS applications is activated. The cardholder selects a VAS application, application A from the implementation class of DF_PT or DF_AD. 4. The service terminal inspects the VAS container through the operation selection of a VAS application on whether the selected VAS application that has PIXA has already been loaded on the card. If the answer is affirmative, an error signal is presented. If not, a check is made as to whether an object of the appropriate implementation class for A is still available in the VAS container. This continues searching for a free record in EF_DIR (e.g., using the SEARCH command). If nothing is available, an error signal is displayed. If a record is -
free, this contains a FIDJJF x of a DF_X where no VAS request has been loaded. 5. The next free object of the appropriate implementation class for A is loaded with the VAS request A. For this purpose, the service terminal first requests to be out of line with the VAS provider (eg, through a SAM of the VAS provider) two keys j ^? A and K? A and assigns these to the new VAS application : • SELECTION FILE < FIDDF X > • BUILDING CHALLENGE • EXTERNAL AUTHENTICATION < Kso (random number), KID of Ks0 > • - UPDATE KEY < KID from KLVASP, KLVASP > • UPDATE KEY < KID from KRVASP, KRVASP > • BUILDING CHALLENGE • EXTERNAL AUTHENTICATION < KLVAgp (random number), KID of KLVASP > • UPDATE REGISTRATION < SFI of EF_INFO of DF_X, DATA > • UPDATE REGISTRATION < EF_INTERNO SFI of DF_X, data > • Optional (initiation): UPDATE REGISTRATION < SFI of EF_VALOR of DF_X, data > 6. After satisfactory entry into the EFs, the service terminal performs the operation of inputting the VAS application < PIXA, FIDjjp x > , that connects the DF_X with PIXA and in this way allows the SELECTION FILE by means of PIXA (after the previous selection through the AIDVAs SELECTION FILE) • The mechanism that has been available through the transfer storage, for example , can be used by VAS providers who wish to carry out intraservices or interservices without proprietary DF structures. A card holder in particular before using this VAS application, does not need to first load this into a service terminal. On the other hand, a voucher certificate or a receipt can be issued directly to the dealer's terminal and redeemed in a different terminal (by means of the removal operation) or simply present a voucher certificate or receipt (by reading). The load of a VAS application of the implementation class EF_TRANSFERENCE is therefore implicitly performed by adding the VAS data or is caused by this operation. In this context, reference is made to the description of the purchase of the class of - -
implementation of EF_TRANSFER additionally, below. The operation of entering a VAS application is described below. If a VAS application has been loaded into the VAS container, a terminal will not know the physical location where DF_X in which X = PT] _, ..., PTp, AD] _, ..., Ada has been loaded the VAS application or if it has been loaded. From the aspect of the card manufacturer, two modes of implementation are possible, which are going to be checked separately; in this context, the consistency of the ZKA standard must be observed with particularity. The first situation: Access EF_DIR is possible. The following preconditions must be filled: • An EF_DIR (e.g., under DF_VAS), where the AIDs are associated with the FIDs of the DF_X where the VAS applications currently exist in a normal manner on the card platform. • This EF_DIR is able to be read by anyone (AC READING REGISTER: ALW). • If the application A of VAS with PIXA is loaded by the operator of the system in a DF X, free (not used), that is, an entry is made in the existing Elementary Files of DF_X (no ARCHIVE OF CREATE!) , then it should be possible to extend the EF_DIR database by entering PIXA through an UPDATE REGISTER that refers to this DF_X through FIDX. The FESS of UPGRADING REGISTER therefore must enforce an external authentication by means of the Kg0 key. If the command FILE SELECTION < PIXA > after the previous selection DF_VAS is transmitted to the card, the DF_X where the VAS request A has been loaded must be directly selected. If a VAS application A, loaded in DF_X and its Subsidiary Elemental Files must be deleted in the service terminal at the request of the cardholder, the corresponding databases are not selected through the SUPPRESSION FILE, but the admitted data are simply written with simulated values . It should then be possible to delete the PIXA input from the EF_DIR (more specifically the PIXA pair and the DF_X reference) (eg, by means of the UPDATE LOG with previous external authentication via the K or key) • Since the DF_X number is set, the number of the EF_DIR registers is known.
- -
If this approach is feasible, the following consequences result: • Direct selection of a VAS application is possible using the PIXA SELECT FILE after the selection of DF_VAS. The second situation: It is not possible to access EF_DIR. If there is no EF_DIR available with a specific card platform with no read or write access for this EF_DIR - as described in the previous paragraph - provision must be made under DF_VAS for an EF_VASDIR database to be made a connection in the VAS application loaded with PIXA to its physical storage location in a DF_X, carried out by a system operator using explicit update registration commands (after the previous external authentication before Kgo). The reading and deletion of EF_VASDIR records should be possible as described above. The operation of the operation input of the VAS application proceeds as follows: A VAS application A including PIXA, was previously loaded in free DF_X with FIDDF_X. The registration number including FIDDF_X was entered through the service terminal.
- -
1. SELECTION FILE < AIDVAg > (error presentation if the VAS container is not selectable)
2. PURCHASE CHALLENGE 3. EXTERNAL AUTHENTICATION < Kso (random number), Kso KID > 4. UPDATE REGISTRATION < SFI of EF_DIR of DF_VAS, record of the number with FIDGJF X. PIXA 'FIDDF X > The VAS applications of the DF_PT or DF_AD implementation classes can only be deleted at the request of the cardholder at the service terminal (under the control of the system operator), the VAS applications of the implementation class EF_TRANSFERENCE can suppressed in any place or by any person. When it is deleted, it is necessary to differentiate between the VAS applications of the implementation classes DF-PT and DF_AD, respectively, the implementation class EF_TRANSFERENCE. The deletion of this VAS application for the implementation class DF_PT or D_AD continues as follows: 1. The cardholder inserts a VAS card into a service terminal. 2. The service terminal checks if a VAS container is present: - -
• SELECTION FILE < AIDV g > (Error presentation if the VAS container is not selectable). • READING REGISTER < EF_ID > (presentation of the VAS container, the ID) The service terminal provides the registrant with a selection of several options. One of them reads suppress the VAS application. This is selected by the card holder. All VAS applications of all implementation classes loaded in the VAS container are now presented to the cardholder and this selection is expected. For this object, the operation of viewing the VAS applications is activated. The cardholder selects a VAS application A from the implementation class of DF_PT or DF_AD through AIDA. The object on which the VAS application is loaded is supposed to be represented as DF_A. After the selection of DF_A, the service terminal is also authenticated: SELECTION FILE < PIXA > CHALLENGE CHALLENGE
EXTERNAL AUTHENTICATION < Kso (random number), KID of Ks0 > The contents of the DF A files are now deleted -
(KLVASP is required for EF_TECLA, EF_INTERNO and EF_VALOR, for which reason the first one is deleted first by the system operator): • UPDATE KEY < KLVASP KID, "00.. 00" > • UPDATE KEY < KID from KRVASP, "00 ... 00" >
• BUILDING CHALLENGE • EXTERNAL AUTHENTICATION < KLVASP (random number), KID of KLVASP > • UPDATE REGISTRATION < SFI of EF_INFO of DF_A, "00 ... 00" > • UPDATE REGISTRATION < EF_INTERNO SFI of DF_A, "00 ... 00" > • UPDATE REGISTRATION > SFI of EF_VALOR of DF_A, "00 ... 00" > ~~ After successful entries in the EFs, the service terminal subsequently causes the entry of the VAS application to be deleted from EF_DIR. • SELECTION FILE < AIDVAS > (presentation of error if the VAS container is not selectable) • UPDATE REGISTRATION < SFI of EF_DIR of DF_VAS, registration number with FIDDF_A,
"00 ... 00", FIDDF_A > The PIXA 'interlace to DF_A is undone since the PIXA SELECTION FILE is no longer possible.
- -
The following is the implementation class of EF_TRANSFERENCE: A VAS application of the implementation class EF_TRANSFER, in accordance with R &R, can only be deleted from the explicit request of a cardholder in a terminal of the operator or service terminal (although this could be thermally feasible by any). The deletion of an EF_TRANSFER object becomes necessary in particular if the transfer store does not have more space to store a new object (e.g., a certificate or receipt or a receipt). The suppression always proceeds indirectly through the supplementary command TOMAR. This command only marks an object as having been removed. Then it is released to be overcome by a subsequent supplementary command of TRANSFER. The deletion of this VAS application continues as follows: 1. The cardholder inserts a VAS card in a terminal capable of presenting the content of EF_TRANSFERENCIA (special case of seeing the operation - of VAS applications). 2. The terminal checks if the VAS container is present: -
• SELECTION FILE < (error presented if the VAS container is not selectable). • READING REGISTER < SFI of EF-ID, 0 > (presentation of the VAS container ID) The terminal makes a selection of several options available to the cardholder. One of them reads suppress the VAS application. This is selected by the card holder. At least the VAS applications of the EF_ TRANSFER implementation class are now presented to the cardholder and a selection is expected. This is done about a special case of the operation of viewing the VAS applications. The cardholder selects a.-Object of the implementation class including a verified certificate or receipt. This object has a registration number A. The card holder activates the selection. The terminal marks the record with the record number A as it is removed as it transmits A, a random number calculated by it as PIX and the terminal ID, using the command TAKE: • TAKE < random number A, PIX, terminal ID > - -
The record marked as having been removed is now available again to receive a certified voucher number or a receipt. The selection of the VAS application continues as follows: In case a VAS application A of the implementation class DF_PT or DF_AD has been loaded into the VAS container by the operation of loading the VAS application, this is You can select through a terminal in two stages. First, the VAS container is selected and then the VAS application including its PIXA: 1. The SELECTION FILE < AIDVAg > (presentation of error if the VAS container is not selectable) A service terminal is able to check the authenticity of the VAS container. For that purpose, a service terminal requires internal authentication of the VAS container: • READING REGISTER < SFI of EF_ID, 0 > (presentation of the VAS container, the ID) • INTERNAL AUTHENTICATION OF < random number, KID of - K UT > The service terminal checks the response and interrupts the operation in case of an error (with error presentation). 2. SELECTION FILE < PIXA > (presentation of error - -
if the VAS application has not been loaded into the VAS container) A dealer terminal (which no longer has KGKA / t available) can indirectly determine the authenticity of the VAS container by authenticating the application A of VAS.
This is because the VAS application may only have been loaded into a service terminal that has verified the authenticity of the VAS container during the loading procedure. The authenticity check of the VAS application A can be returned to the test at the dealer's terminal whether the VAS container contains the KLVAg or KR? SP For the application A of VAS. This can be checked by the dealer's terminal, v.gr, in the following way: • INTERNAL AUTHENTICATION <; random number, KID of RVASP ° KLVASP > In order to test if the application has been loaded
VAS in the VAS container, can be selected randomly; based on the error presentation of the response message of the SELECTION FILE, being able to reach the conclusion that it is not present. A selection of a VAS application of the implementation class EF__TRANSFERENCE results implicitly through the operation of viewing the -
VAS applications and the storage of data in the terminal. Since the terminal knows the registration number of each indicated object of the EF_TRANFERENCE, it is possible to select any desired object for further processing with reference to the registration number. The operation of a VAS application continues as follows: The operation of viewing the lists of VAS applications in a service terminal all the applications of
VAS of the implementation classes DF_PT, DF_AD and
EF_TRANSFERENCE. Only the VAS applications of the implementation class EF_TRANSFERENCE can be presented to a terminal of the operator due to the lack of access protection for it and optionally also the applications of the implementation class
~~ DF_P? ~~ or DF_AD for which the dealer's terminal has reader rights (possession of KR? Agp). This VAS ~ application continues as follows: 1. The card holder inserts a VAS card (chip card with a valid VAS container) in the terminal. 2. The service terminal tests whether the VAS container is present: - -
• SELECTION FILE < AIDVAS > (error presentation of the VAS container not selectable)
• READING REGISTER < SFI of EF_ID, 0 > (presentation of the VAS container ID) Optionally the validity of the VAS container is checked. For this purpose, the service terminal requires internal authentication of the VAS container: • INTERNAL AUTHENTICATION < random number, KAUt KID > The service terminal tests the response and in case of an error (with error presentation) interrupts the procedure. The service terminal presents the card holder with a selection of several options. One of these reads and sees the VAS applications. This is selected by the card holder. The service terminal is also authenticated: • BUILDING CHALLENGE • EXTERNAL AUTHENTICATION < Kso (random number), Kso KID > For VAS applications of the implementation classes DF_PT and DF_AD the individual VAS applications are selected, controlled -
successively through the content of EF_DIR and, after external authentication with the K key or the individual EF_INF0 content (or part thereof according to R &R) as well as the EF_VALOR are presented: • For i = 0, ... , nrpjiR - 1 • READING LOG < SFI of EF_DIR, i > In the response, the PIXA message is displayed which is "00..00" if the corresponding DF is not loaded with a VAS application. As an alternative to the READING REGISTER of EF_DIR it may also be possible to use a SEARCH command. • If PIXA is not equal to "00..00" • SELECTION ARCHIVE < PIXA) > • READING REGISTER < SFI of EF__INFO, 0 > • It is presented (optionally only a part) of the response message • READING RECORD < SFI of EF_VALOR, 0 > • SELECTION FILE < AIDVAS > For VAS applications, f, the implementation class of EF_TRANSFER the content (or a portion thereof according to R &R) of the -
EF_TRANSFERENCE of each record is presented: • SELECTION ARCHIVE < AIDVAS > • If = 0, ..., nrEF_TRANSFERENCE ~ 1 • READING REGISTER < SFI of EF_TRANSFERENCE, i > (the response message presents the contents of the i-th registers of the EF TRANSFER) • If the contents are not empty, the content is presented in interpreted form (e.g., extracted / expired). The visuality of the applications of the implementation class DF_PT or DF_AD for which the dealer's terminal has vision rights (possession of? Gp), progress as described - subject to two changes: For external authentication of the Kp key? Agp is used instead of Kgo which is only available to the system operator. If the dealer terminal does not have KQJ ^ UT and yet wishes to check the authenticity of the VAS applications, the merchant terminal instead of the internal authentication can demand authentication (at least one) of the VAS application. This progresses as described by the knowledge of the key card of KR? A p or R £. corresponding gp.
- -
For the VAS applications of the implementation class EF_TRANSFERENCE the content (or a portion thereof according to R &R) of EF_TRANSFERENCLA of each record, are listed successively as described above. The operation of the interpretation of VAS applications advances in a similar way to it. For that purpose, the terminal offers the card holder an option interpretation of the VAS applications for selection. In addition to the data that is presented due to the visualization operation, it is also possible to present the data of the EF_INF0 and EF_VAL0R that require interpretation by the VAS provider (eg, externally encoded data) and the EF_INTERNO data (eg, miles or kilometers). of previous years with Miles and More). However, this is only possible for VAS applications for which the VAS provider (at its own option) makes it possible to be available on the appropriate keys of the terminal. The key? L? A p (external authentication) is required to read EF_INTERNO from a VAS application. For externally encoded data within the Element Files EF_INFO, EF_INTERNO and EF_VAL0R as well as transfer storage of EF_TRANSFERENCLA, the appropriate keys of the VAS provider are required. The terminal program -
you can easily distinguish with the PIX help of the selected VAS application, for which application keys are available for the interpretation of the data. The application transfer operation of
VAS represents the transfer of all of the VAS operations selected from a source card to a registration card in a service terminal. This is an object to the precondition that in the VKAS container of the reference card, VAS applications are not loaded and that after the transfer of all VAS applications is deleted from the source card. Both can be achieved by successive applications of the operation to suppress a VAS application. In addition, the authenticity of the VAS card should be checked if the reference card should provide adequate storage capacity. The transfer operation itself is essentially based on an extension of the visualization operation of the VAS applications for which the data is read in addition to the EF_INTERNO and the K-LVASP and KR? A p keys, and in a repeated application of the load operation of a VAS application. In conjunction with the VAS data, the VAS container ID is also transferred to the reference card so that the VAS applications of the -
Reference card hold out exactly as they did on the font card. The reasons for this is that the keys derived from a VAS provider are supported by the VAS container ID, however, the keys have been copied without any change. In addition, a VAS provider does not want to change its account in the basic system because it normally identifies the VAS cards through the VAS container, the ID. It is essential to ensure that during the transfer of the VAS container the ID, this number that is unique to the system is deleted from the source card. In order to be able to read specifically the EF_INTERNAL Elemental File and the keys KL? A and KR? Agp, the service terminal, after an external authentication by means of the Kgo key (as an operation that suppresses a VAS application) first overwrite the KL key A and then after renewed authentication with KL? A p overwrite the data of the EF_INTERNAL. In addition to the VAS applications of the DF_PT and DF_AD implementation classes, the EF_TRANSFERENCLA file must be overwritten. Due to this object, the remove operation is used successively to remove objects of this implementation class that have not yet been marked as having been removed or expired, check your signature through Kgjg? Asc Y Heve - -
carried out the transfer to the EF_TRANSFERENCE of the reference card. On the reference card, on the other hand the objects are represented as having not been removed so that they will remain valid. Finally, the global data of the container of
VAS must be transferred. In particular, the sequence number of the reference card must be adjusted to the value of the source card. The procedure for entering VAS data is described below: There are three possible cases to support VAS data in a dealer terminal that depend on the nature of the VAS application. First, the purchase in the case of the implementation class DF_PT or DF_AD A VAS provider must support the data in a VAS application A of the implementation class DF_PT or DF_AD. Admission of VAS data continues as follows: 1. The cardholder inserts a VAS card into a dealer's terminal. 2. The dealer terminal checks if the VAS container is present: • SELECTION FILE < AID? AS > (presentation of -
error if the VAS container is not selectable) • READING LOG < SFI of EF_ID, 0 > (presentation of the VAS container ID) 3. The authenticity of the VAS container is checked. If the dealer terminal itself is in possession of the master KGKAuT 'key, an internal authentication of the VAS container can be demanded: • INTERNAL AUTHENTICATION < random number, -KID of KAUT > A dealer terminal (which KGKAut does not have available) can indirectly verify the authenticity of the VAS container by authenticating the VAS application A. The reasons is that a VAS application could not have been loaded into a service terminal that during the load had checked the authenticity of the VAS container. The verification of the authenticity of the VAS application A can again refer to the test of the dealer's terminal as to whether the VAS container contains the L? Agp key or the KR? ASp key for the VAS application A. This can be checked by the dealer's terminal, e.g. through: - -
• SELECTION FILE < PIXA > (presentation of error if the VAS application A is not loaded in the VAS container) • INTERNAL AUTHENTICATION < random number, KID of KRVASP or KL? ASP > The dealer's terminal checks the response and in case of error (with error presentation) interrupts the procedure. 4. The dealer terminal selects the VAS application A, authenticates itself and describes the Elemental Files that are necessary to carry out the transaction: • SELECTION FILE < PIXA > (it is avoided if it was already carried out in step 3) • OBTENTION CHALLENGE • EXTERNAL AUTHENTICATION < KLVASp (random number), KID of KL? Agp > • optional: UPDATE REGISTRATION < SFI of EF_INFO of DF_X, data > • optional: UPDATE REGISTRATION < EF_INTERNO SFI of DF_X, data > • optional: UPDATE REGISTRATION < SFI of EF_VALOR of DF_X, data > Now follow the case purchase of the implementation class EF TRANFERENCE - -
Specifically for VAS applications of the implementation class EF_TRANSFERENCE (Certificate of Proof of the application class), a VAS provider does not need to occupy a file structure of property DF_X for this application. The result is that the cardholder does not need to go to a service terminal in order to load a VAS application before using the VAS application certificate. Instead, you can issue a verifiable certificate or receipt directly to the merchant's terminal and have them reimbursed to a different terminal (by removing the transaction) or simply show the verifiable certificate or receipt (by reading). The admission of the VAS data correspondingly results in an implicit load of the VAS applications of the implementation class EF_TRANSFERENCE. For this application class there is the class of the EF TRANSFER implementation class that is composed of individual objects of the record type. An entry in EF_TRANSFERENCE is possible exclusively by the transfer control. The dealer's terminal for that purpose must be in possession of a valid K ^ C cancellation key and must have a PIXA of the VAS application A available.
- -
The admission of the VAS data continues as follows: 1. The cardholder inserts a VAS card in a terminal of the merchant. 2. The dealer's terminal checks if a VAS container is present: • The SELECTION FILE < AIDVAS > (presentation of error if it is not selectable in the VAS container) • READING RECORD < SFI of EF-ID, 0 > (presentation of the VAS container number)
3. The dealer terminal reads the sequence number that is also supported by the MAC in step 4: • READING REGISTER < SFI of EF_SEQ, 0 > (presentation of the sequence number) 4. The TRANSFER command causes a record to be admitted in EF_TRANSFERENCE: • TRANSFER < transaction data, expiration date, generator code, data, PIX, MAC with KQEC > 5. The merchant's terminal can check by inspection of the response message of the TRANSFER command if the VAS container is genuine (ie, in possession of the attached secret KGJEC). In this context, reference is also made to the response message after the TRANSFER command, described further in the foregoing. Finally, the purchase of the VAS data by means of value cancellation A VAS provider can be a value cancellation step using the TRANSFER command in the transfer field EF_TRANSFERENCE generate a title (eg, certificate or receipt or receipt) that also it can be used by a different VAS provider. The data is canceled from the EF_VALOR or EF_INFO of the VAS application A of the VAS provider by performing the cancellation. The holder of the card acquires the right in the form of an object in EF__TRANSFERENCIA. The entry of the VAS data continues as follows: 1. The cardholder inserts a VAS card in the dealer's terminal. 2 . The dealer terminal checks if the VAS container is present: • SELECTION FILE < AIDVAS > (presentation of error if the VAS container was not selectable) • READING REGISTER < SFI of EF_ID, 0 > (presentation of the VAS container ID) 3. The dealer's terminal reads the sequence number -
which also supports the MAC in the course of step 4: • READING REGISTER < SFI of EF_SEQ, 0) > (presentation of the sequence number) The dealer terminal selects the VAS application A: • SELECTION FILE < PIXA (error presentation, if the VAS application A has not been loaded in the VAS container) The dealer terminal uses the TRANSFER command to cancel the EF_VALOR or EF_INFO data, as the case may be. • TRANSFER of < data, MAC with KDEC > The composition of the TRANSFER command message has already been described. The entitlement to carry out the cancellation is obtained through the terminal if it can form a correct signature related to the data by means of KDEC * This signature is checked by means of the VAS container. If successful, a record is established in EF_TRANSFERENCLA using the VAS container and the number of sequences is increased. The dealer's terminal can check by checking the response message of the TRANSFER command, if - -
the VAS container is authentic (that is, in possession of the common KGJEC secret) • We will now deal with the procedure to cancel the VAS data. There are two types of cancellation procedures: On the one hand, the VAS data for VAS applications of the implementation class DF_PT or DF_AD can be canceled by the appropriate VAS provider by canceling the operation, ie the purchase of VAS data by cancellation. In this way, a value is consumed by which a potential entitlement to a different value is created. On the other hand, the VAS data can be removed from EF_TRANSFERENCLA once only through the command of supplementary TOMAR. In this case, the title is consumed, the data remains for additional use possible
(e.g., the reimbursed ticket is still required for the return trip) in the transfer field, represented as having been removed until it is countered by other objects, when required. The cancellation of the VAS data through the command of TOMAR proceeds as follows: 1. The cardholder inserts a VAS card in a terminal of the dealer. 2. The dealer's terminal checks if available - -
a VAS container: • SELECTION FILE < AIDVAS > (presentation of error if the VAS container is not selectable) • READING RECORD < SFI of EF_ID, 0 > (presentation of the VAS container, and ID) 3. The dealer terminal first presents from EF_TRANSFERENCLA the objects that are not available using the special case of visualization operation of VAS applications in order to decide if a required object is available. Alternatively, the SEARCH command can be used to search for a sample. The terminal, if satisfactory, knows the number i of the record that is sought. 4. The terminal marks the record to show the number i of the record as it transmits i, a random number calculated by it, its PIX and the terminal ID with_the command to TAKE: • TAKE < i, random number, PIX, terminal ID > The dealer terminal uses the TAKE command to read the EF_TRANSFER data, which simultaneously identifies the data as having been extracted. The execution of the command also carries out the generation of two different cryptograms C] _ and C2.
- -
The cryptogram C] _ is calculated using the VAS container using the K jg? Agc key. In this way the producer of the removed object signed with C_ can obtain evidence of the singularity and authenticity of the system operator. The uniqueness and authenticity of the transaction arises from the cryptogram of the VAS provider from which the object was originally originated (and checked by the card, see also TRANSFER), and from the maintenance of the sequence counter through transactions like this. as the cryptogram C] _, by means of the card, during the withdrawal. The cryptogram C2 is calculated by the VAS container using the K-GKDEC 'key which is derived by the VAS container of KGKDEC-PIX and the terminal ID. Having knowledge of the attached secret KQEC, the VAS container can verify directly in the terminal the authenticity of the VAS container. Due to the fact that during the TRANSFER command a check is also carried out that only comparable certificates or authentic receipts are stored in an authentic VAS container, the authenticity of the removed object can be considered as concluded. Since C2 is formed indirectly through the sequence number, the withdrawal bit and the VAS container the ID, the VAS container - -
You can still verify in the terminal the singularity of the removed object. Anyone has the right to withdraw using the command TAKE. In addition, deactivation or activation, respectively, of a password or PIN protection for reading the VAS applications of the implementation classes DF_PT and DF_AD is also possible in the service terminal. In addition, the PIN of the VAS container can be altered by the owner of the card who is aware of the PIN and can be reset by the operator of the system by means of external authentication by means of K o- The non-numeric symbols or the length symbol sequences Optional can also be used as PIN or password.
Claims (34)
- CLAIMS: 1. A chip card to carry out transactions where the monetary units or other value data they represent in non-monetary terms are transferred between the cardholder and at least one partner of the transaction (service provider) or are presented to the service provider for verification of the intitulations, wherein the chip card includes a storage, wherein the data required to carry out the transactions are stored and the chip card is characterized in that it comprises the following: a means to load a or more card applications (VAS applications) that are assigned to a certain service provider, respectively, to the card where each one allows the operation of the transactions between the cardholder and the service provider assigned to the application; a portion of transfer memory (EF_TRANSFERENCE) that is not owned by the service provider to accommodate the data that in the operation of a transaction between the different service providers that are going to exchange or will be presented and that represent the monetary units or non-monetary terms; and a means for writing the data in a transfer store by reaction to a write command (Transfer).
- 2. The chip card according to claim 1, wherein the means for loading comprise: a data structure (DF_VAS, container-of VAS) stored therein that includes: a partial structure (DF_PT, DF_AD, application of VAS) where the required data can be loaded (VAS data) to enable the operation of a transaction between the cardholder and a service provider. a set of definition data that contains information related to the nature and / or structure of the data stored in the partial structure (application of VAS); and wherein the definition data set further comprises: a denotation (container-ID) that identifies the data structure (VAS container) and / or the chip card; and at least one system key (Kgo) that ensures the integrity of the definition data set and / or the data structure (VAS container) against modifications.
- 3. A chip card according to claim 1 or 2, characterized in that it comprises at least one of the following features: a means to load the necessary data for the operation of the transactions in the partial structure with the help of minus one system key; means for writing the data in the definition data set to adapt the data of the definition data set to the data loaded in the partial structure; means for generating an additional partial structure in which the data required to carry out a transaction in the card database can be loaded; and / or a means of managing dynamic memory in the card.
- 4. A chip card according to any of the preceding claims, characterized in that the partial structures (VAS applications) that are represented by mutually independent partial structures are assigned one of them to a specific service provider, - - the definition data set is protected against modification by at least one system key •? S?) And can only be modified by means of this key, and that the loading of the partial structures (VAS applications) can proceed only with the use of the system key contained in the definition data set.
- 5. The chip card according to any of the preceding claims, characterized in that the definition data set comprises at least one of the following features: at least one authentication key (K rjt) to authenticate the intitulation of the chip card in relation to a terminal and / or for authentication of the intitulation of a terminal in relation to the chip card. at least one signature key (Kg g VASC) to sign the data removed from the transfer storage; a key that generates a key C ^ -GKDEC ^ to generate the keys of the terminal and application specific for the verification of the authorization for a - writing procedure towards transfer storage and / or invalidation of value data; a PIN for the verification of the authorization of a transaction procedure by the cardholder, that to the system key (K o), the authentication key (K ut) and the signature key (g Q VASC) Y ^ -a key that generates the C & GYSJEÓ key are individual keys to the cards or specific to the data structure (DF_VAS), and that the partial structure (VAS application) comprises at least one of the following characteristics: at least a storage of value (EF_VALOR) for the storage of the value data; at least one internal storage (EF_INTERNO) for the storage of internal data related to the partial structure; at least one storage of information (EF_INFO) for the accommodation of non-internal data related to the partial structure; a key storage (EF__TECLA) to accommodate at least one key (KLV SP-KRVASP) '< 3ue provides security for the writing and / or the information retrieval procedure to and from - the storage of value, and / or the internal storage and / or the storage of information and that of the chip card also includes: a means to write and / or recover the data to and from the storage of value, the internal storage on the storage of information and that the means to load includes: a means to write the key in the storage of keys that is protected by at least one key of the system.
- 6. A chip card according to any of the preceding claims, characterized in that the partial structure comprises at least one of the following integers: a key (KL? Gp) to check the authorization to write the data in the structure partial: a key (K? A p) to check the authorization to recover the data of the partial structure.
- 7. A chip card according to any of the preceding claims, characterized in that the keys stored in the key storage are specific to the respective partial structure and that at least one partial structure (VAS application) protects the operation of the keys. the transactions by - means of at least one of the specific keys (KLVASP 'KRVASP) which is specific to the respective partial structure (VAS application) and which is independent of the keys for the other partial structures (VAS applications). The chip card according to any of the foregoing claims, characterized in that the card comprises a plurality of partial structures (VAS applications) each serving the operation of the transactions between the specific service provider and the owner of the card, and that the operation of the transactions includes the writing and / or retrieval of data towards, respectively from the transfer field and / or the writing and / or the retrieval of data towards respectively out of the value storage. 9. The chip card according to any of the preceding claims, characterized in that it also includes: a means to carry out transactions both between the individual partial structures (VAS applications) as well as between a partial structure and a provider of service. 10. The chip card according to any of the preceding claims characterized in that the system key (Kgo) is known only to the system operator (SO) and is an individual key for a card and / or specific to a data structure (VAS container), and that the additional keys contained in the definition data set are individual keys for the card and / or specific for the data structure (VAS container). 11. The chip card according to any of the preceding claims, characterized in that the definition data set includes one or more of the following integers: an identification number (EF_ID) specifies the data structure a directory of partial structures (EF_DIR) contained in the data structure, the directory contains numbers of specific identification for the partial structure of the partial structures (VAS applications) loaded into the data structure (VAS container), as well as the information that contains that part of the data structure (VAS container) where the - Partial structures (VAS applications) are physically stored; a version number of the data structure (EF_VERSION). "12. The chip card according to any of the preceding claims, characterized in that it includes at least one of the following features: a means to carry out a withdrawal procedure (Take) by means of which the data can be Removal and / or the value can be canceled from the transfer storage, a means to generate one or more particularities of authenticity of the data during the withdrawal or cancellation of the data from the transfer storage 13. The chip card in accordance with any of the foregoing claims, characterized in that the chip card for generating authenticity features comprises the following: a signature key (Kgig VASC) for generating a digital signature having the data removed, a means for generating a transaction number that characterizes the transaction that is also used in the generation of the digital signature. 14. The chip card according to any of the preceding claims, characterized in that the signature key (Kg Q? Agc) is a private key, derived from a private key that generates the key and that for the verification of the signature by means of the service provider, public keys are used. The chip card according to any of the preceding claims, characterized in that it at least comprises one of the following integers: a means for generating a terminal and specific keys of the partial structure (K ^ EC) by means of the key generating key (K-GKDEC 'means to verify the authorization and / or protection of a transaction using at least one of the following integers: the specific key of the terminal and the partial structure (KDEC.I at least one authentication key (KAGJT) * - at least one system key (K o), at least one specific key of the partial structure (KL? ASP, KRVAgp), the signature key (KSIG VASC) 'the PIN, the identification of a partial structure, - - the identification of a terminal. 16. The chip card according to any of the preceding claims, characterized in that the chip card includes at least one of the following integers: a means for authentication of the authority and / or the terminal by means of the key of authentication before starting a data recovery or write procedure, a means for carrying out data recovery or write procedures that are protected by a digital signature and / or key formation. 17. A chip card according to any of the preceding claims, characterized in that the chip card also includes at least one of the following integers: a means for activating and deactivating PIN protection. a means to change the PIN. 18. A chip card according to any of the foregoing claims, characterized in that the data structure according to any of the foregoing claims is independent of the card platform and the chip card further includes: - a means for transferring the data structure or parts of the data structure to another card. 19. The chip card characterized in that it comprises the following: - Tina storage region not owned by the service provider for writing or retrieving data to or outside the storage region by different service providers for the transfer of monetary units and / or value data that represent other non-monetary entitlements between different service providers. 20. The terminal for the use of a chip card according to any of claims 1 to 19 characterized in that the terminal comprises: a means to identify the data structure (VAS container) of the chip card as well as to identify the characterization (container-ID) that identifies the data structure; and further comprising at least one of the following features: a means for recovering the data from at least one of the partial structures and / or the definition data set and / or the transfer storage of the card; - - a means for writing data to the transfer storage of the card; a means to load the data required for the operation of the transactions in at least one of the partial structures (VAS applications) of the card. 21. A terminal according to claim 20, characterized in that it comprises at least one of the following integers: a ü-iedio to carry out the transactions between a service provider and the cardholder wherein the operation of a transaction includes at least one of the following steps: the writing of the data to the value storage, the writing of the data to the transfer storage, the removal and / or cancellation of the data from the transfer storage, the Data recovery from partial structure, data recovery from transfer storage. - 22. The terminal according to any of claims 20 or 21, characterized in that it further comprises: means for verifying authorization for and / or protection of a transaction with the help of at least one of the following integers: a terminal and a key specific to the partial structure (KDEc .. at least one authentication key (KATJT) that is individual for the card or specific to the data structure (DF_VAS), at least one system key (go) that is individual for the card or specify for the data structure (DF_VAS), at least one key specified for the partial structure (KLVASP, KRVASP), at least one signature key (KgjQ VASC ^ (3ue is individual for the card or specific for the data structure (DF_VAS), a PIN that is individual for the card or specifies for the data structure (DF_VAS), a specific characterization of the application of a partial structure, a character specific erizadión of the terminal of a terminal. - 23. The terminal according to any of claims 20 to 22, characterized in that the means for writing the data in the transfer storage comprise: 5 means for encoding the data with the use of a terminal and a specific key of the partial structure ( KpEc) for verification of write authorization. 24. The terminal according to any of claims 20 to 23, characterized in that? 10 further comprises: means for carrying out a process of removing the data from the transfer storage by means of which the data is removed from the transfer storage and / or canceled in value. 25. The terminal according to any of claims 20 to 24, characterized in that (I further comprises at least one of the following integers: a means for characterizing the transfer storage data as having been removed, a means for characterizing the transfer storage data as having expired. any of claims 25 to 25, characterized in that the means for carrying out the transactions comprise at least one of the following integers: a means for changing the value data in the partial structure; a means for carrying out the transactions between different service providers (interservices) at expense respectively for the benefit of the cardholder. 27. The terminal according to any of claims 20 to 26, characterized in that it further comprises: a means for the authentication of the terminal authority in relation to the card and / or the card in relation to the terminal with the help of so minus an authentication key; a means to protect a transaction by the cardholder by means of a PIN; a - means to activate and deactivate PIN protection. 28. The terminal according to any of claims 20 to 27, characterized in that it also comprises at least one of the following integers: a means for transferring a specific characterization from the terminal to the card; - a means for transferring a characterization specifying the partial structure to the card; means for authentication of the authorization using a terminal and a specific key of the partial structure as well as the terminal and the specific characterization of the partial structure, a means for carrying out data recovery or writing procedures that are protected by the digital signature and / or coding. 29. The terminal according to any of claims 20 to 28, characterized in that it also comprises at least one of the following integers: a means -to select a partial structure (VAS application); a means to see a partial structure in the terminal; a means to see the data of a partial structure in the terminal; a means to load a partial structure (application of VAS) on the card; a means to load a characterization in the partial structure loaded (VAS application) .in the card, - a means for suppressing a partial structure from the card, a means for submitting a partial structure by a different partial structure; a means for transferring a partial structure to another card; a means to interpret a partial structure with respect to its function and its associated service provider as well as for data recovery and to view the information stored therein. 30. The process to carry out transactions between a cardholder and at least one service provider that involves the use of a chip card as well as a terminal where the process comprises one of the following steps: Provision of a data structure stored in the chip card of a card application owner to a service provider can be loaded to allow operation of the transaction between the card holder and the service provider (VAS data); as well as writing in or reading the data from the data structure (VAS application) to carry out the transactions between the cardholder and the service provider; - the provision of a transfer storage region (EF_TRANSFERENCE) that is not owned by a service provider for the storage of monetary or other units that represent non-monetary terms that are to be exchanged or presented during the operation of the transaction between the different service providers, as well as data writing in transfer storage or transfer storage data recovery. 31. The process according to claim 30, characterized in that the process comprises at least one of the following steps: Using a chip card according to any of claims 1 to 19; using a terminal according to any of claims 20 to 30; write or retrieve the data to or from the storage of value of the internal storage or storage of information from at least one of the partial structures (VAS applications). 32. The process according to claim 30 or 31, characterized in that it also includes at least one of the following steps: authentication of the terminal authority and / or the chip card with the use of at least one key; Protection of the transaction by using a digital signature and / or coding by using at least one key. 33. The process for loading the data into a chip card using a terminal, characterized in that the process comprises at least one of the following steps: Loading the data in the partial structure (VAS application) of the card; writing the data in the card definition data set, the process comprises at least one of the following steps: use of a chip card according to one of claims 1 to 19; the use of a conformance terminal as claimed in one of claims 20 to 29. 34. The system for carrying out transactions, characterized by a chip card according to any of claims 1 to 19, and a terminal according to any of claims 20 to 29.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE19654187.5 | 1996-12-23 | ||
| DE19718115.5 | 1997-04-29 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| MXPA99005832A true MXPA99005832A (en) | 2000-09-04 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6249869B1 (en) | Integrated circuit card, secure application module, system comprising a secure application module and a terminal and a method for controlling service actions to be carried out by the secure application module on the integrated circuit card | |
| CA2345391C (en) | Loyalty file structure for smart card | |
| US7010701B1 (en) | Network arrangement for smart card applications | |
| AU2007203383B2 (en) | Online payer authentication service | |
| CA2117440C (en) | Integrated point-of-sale multiple application system | |
| US8244636B2 (en) | Payment system | |
| US6023508A (en) | Polymorphic data structures for secure operation of a virtual cash system | |
| US20030070080A1 (en) | Electronic-monetary system | |
| KR20000069703A (en) | Chip card and method for its use | |
| CN108650279A (en) | Network information security acquisition method and network trading method and network safety system | |
| AU738719B2 (en) | Chip card and method for its use | |
| JP2003504759A (en) | System for executing transactions | |
| KR101065423B1 (en) | Method for Issuing Card by Local Travel Agency Affiliated with Overseas Store and Program Recording Medium | |
| MXPA99005832A (en) | Chip card and method for its use | |
| CN108694585A (en) | The internet trading system of compound authentication | |
| KR101017063B1 (en) | Method for Processing Payment and Authentication for Post Issuance of ICC Information | |
| TW491980B (en) | Chip card and its using method | |
| AU709400C (en) | Integrated circuit card, secure application module, system comprising a secure application module and a terminal and a method for controlling service actions to be carried out by the secure application module on the integrated circuit card | |
| EP1204080A1 (en) | Method and system for adding a service to an apparatus comprising a memory and a processor | |
| KR20070072802A (en) | System and method for processing admission of payment corresponded to information of payment time, devices for processing admission of payment and recording medium | |
| KR20080069935A (en) | System for transferring affiliated point or holding it in common | |
| KR20040106647A (en) | System and Method for Transferring Affiliated Point or Holding It in Common | |
| MXPA99000488A (en) | Integrated circuit card system and safe application modulode comprising a secure application module and a terminal, and a method to control the service actions to be carried out by the safe application module so |