Data exchange systems comprising portable data processing units

IS 2 153 455 T3

DESCRIPTION

Data exchange system that includes portable data processing units.

The invention refers to a data exchange system that includes multiple data processing units, some of which, which are portable, establish a temporary communication link and others, which are fixed, may have a permanent communication link with a or more of the rest of the units within the system. The processing units include a data communication means, a processing means and a memory means, the latter including an execution program. The present invention is a generalization of the system claimed in EP0.666.550, which is a previous technique, following what is stated in Art 54 (3) of the CPE.

A similar system is known from the international patent application WO-A-87/07063 in which a system for a portable data carrier having multiple application files is described. One of the most important applications of a portable data carrier like this one is a smart card suitable for multiple applications. The known data carrier is described as a hierarchically structured data carrier with a host of security features to support multiple applications on the same data carrier. Applications are viewed as data sets. The patent application describes an implementation of a hierarchical file system on a data carrier to store alterable data in combination with a hierarchical set of access permissions. The data carrier responds to a set of common commands. File access permissions are different for different operations and are granted depending on the verification of a password. A password verification attempt counter is introduced as well as the prediction of the destruction of the stored data as a penalty for too many access attempts. The known data carrier appears primarily as a storage device and not as a processor. The runtime program alone can carry out very simple functions, such as binary logic operations. It is not possible to execute a non-specific set of operations after the request of a terminal that is communicating with the data carrier. The only security option is the introduction of password verification. No other verification of the access condition is possible within the known system. In addition, each application on the data carrier has its own archive on the storage medium of the data carrier. No special measures are taken to increase the efficiency of the available memory space which, especially in smart cards, is very restrictive and consequently limits the number of possible applications.

EP-A-0,479,655 refers to the implementation of verifications of the access condition in smart cards. A specification technique is included for this, however, it is desirable to establish measures to include the possibility of other verifications of the access condition.

EP-A-0,361,491 refers to a smart card programming system to allow the (re) programming of cards. It describes the use of access conditions by means of a single write to control the access of parts of programmable memory to be programmed. In this way the number of applications of a single card can be increased. Verification of access conditions with a variety of techniques including cryptographic protocols is described.

EP-A-0,292,248 refers to loading applications on a smart card using an unalterable program of the operating system. This includes the implementation of a data access condition execution method using memory zones with assigned access attributes. The specific access conditions are "write once" (which is only implicitly described) and "execute only".

US-A-4,874,935 refers to the programming of cards using a data dictionary where the data dictionary describes the distribution of data items stored in the memory of the card It is commonly believed that data dictionaries differ from directories in that these not only describe the data actually stored, but also describe the data that will be stored later. In addition, data dictionaries usually include a description of the data format. In compiled format, data dictionaries are used in database management systems where they are stored on the hard drive as part of the database. They can also be found in the object load files that result from compiling the program in software development environments. However, the patent does not claim a representation of data dictionaries particularly suitable for electronic cards.

EP 0 466 969 A1 refers to the provisioning functions in the smart card execution program to support the correct conduction of a sequence of messages between the smart card and the terminal reserving part of the card memory as storage for state information and providing the specific means to implement a state engine that controls state transitions. Said status information is crucial when determining the actions to be taken when messages are received. State engines that accept a variable sequence of messages are well known from compilation design of the computer language and a theory on computational complexity. The patent does not refer to the possibility of implementing varied sets of possible actions specific to a number of possible applications that can simultaneously reside on the smart card.

The main objective of the present invention is to present means to describe formally, accurately and uniquely a system2

ES 2 153 455 T3 subject consisting of reliable processing units in the way in which these processing units will behave when they enter into communication with each other, where said communication is intended to transfer values ​​or other reliable information. Such comprehensive descriptions of the possible modes of communication between the data processing units are applicable both to the system and to a unit as well as to the detailed operations of the individual processing devices. Said formal description establishes the basis for formal reasoning when verifying the correctness of the implementations, which will be a requirement for the acceptance of systems destined for a worldwide deployment.

Another objective of the present invention is to present means to be able to optimally cover the restrictions imposed by limited physical dimensions of the memory space available on portable data processing units, especially on smart cards.

Another object of the present invention is to offer a more general mechanism for protected loading of program codes and to allow such loading into multiple programs each for one application of each portable data processing unit.

What is more, the present invention is aimed at establishing the use of the condition of verifications of the access condition not prescribed by the manufacturer of the portable processing unit but chosen by the designer of the application to suit your needs. individuals.

Likewise, the present invention aims to provide a mechanism to protect communication between processing units so that the content and the ordered sequence are not interrupted by any intervention or mediation device.

Consequently, the system following the invention is defined by the figures of claim 1.

By organizing the description of the system of reliable communication processing units in this unique framework, its operations are fully and exhaustively described with regard to the conditions and effects of possible communications between the devices. The data becomes capable of formal reasoning by completing it with formally precise semantic definitions of the elements of the structure and, consequently, the implementation of the system becomes better able to carry out the formal revision of the correction. For this reason it is not necessary for all data to reside on the entire memory medium of the individual processing units. It is sufficient that such data is loaded into a processing unit before it is used. The present invention includes the secure uploading of such data.

In a first preferred embodiment, the individual processing units of the data exchange system described as set out above are defined by the figures of independent claim 2.

As previously indicated, the present invention is aimed at generalizing concepts already claimed in EP-A-0,666,550, which is a prior technique, following the provisions of Art. 54 (3) of the CPE. The scope of protection claimed by EP-A-0.666.550 is defined as follows:

data exchange system that includes at least one portable data processing unit (5) that includes a data communication means (14), a processing means (15) and a memory means (16), the latter includes an execution program (17) characterized in that the memory medium (16) also comprises at least one interaction context (19 (1) ... 19 (m)) that contains the following coherent structure of data:

to. a set of basic communication primitives (A (1) ...) that are accepted as long as the data processing unit (5) communicates with a similar unit (4), primitives that at least include a primitive that is used to selectively introduce one of said interaction contexts (19 (1) ...);

b. a set of descriptions about the procedure (C (1) ...) that defines the actions to be carried out in response to each of the accepted communication primitives (A (1) ...), at least in such a way that include a first description of the procedure to be carried out after the activation of the interaction context, and in such a way that they also include a last description of the procedure to be carried out immediately before deactivating the context;

c. a possibly empty set of data elements (H (1) ...) either permanently stored or well computed, so that they are available to be used when carrying out procedures such as those already defined in the descriptions about the procedure (C (1) ...);

d. a set, possibly empty, of references to data elements, whose references are associated with the descriptions about the procedures (C (1) ...), these data elements can also be accessed for other possible interaction contexts and are available for use when performing procedures such as those defined above in the descriptions about procedure (C (1) ...);

and. a list of data, possibly empty, that includes a list of references (B (1) ...) to data elements that are available for explicit reference as part of a communication primitive (A (1) ... ) so that they can be used by the description of the procedure (C (1) ...) in relation to the communication primitive;

IS 2 153 455 T3

F. a set of access conditions associated with the data elements referred to in association with the descriptions about the procedure (C (1) ...);

g. a set of access conditions associated with the data reference list (B (1) ...) in the data list.

This protection objective is expressly outside the scope of protection claimed by the present independent claims 1 and 2.

By defining the data within the memory medium of the portable processing unit so that the unit not only allows addition and subtraction but also carries out processes that could be loaded into the processing unit by persons authorized to do so. , p. eg, a bank staff member. By supplying procedures that can provide complex arbitrated operations in response to received orders and by supplying an explicit list of stored data items that can be referenced as part of those orders, it can be optimally employed. the width of the communication band; which results in a reduced number of exchanged orders. With a system following the invention, many current uses of the system may require changing two orders. The only thing that remains fixed is the structure within the memory medium that is defined so that different applications of the unit can be added very efficiently, that is, using as little additional memory space as possible. This is especially important if the drive is a smart card that is severely limited in terms of available memory space. In addition, the structure according to the invention offers all the possibilities to include security measures in order to prevent unauthorized persons from accessing processes or data that they do not have the right to use.

An advantageous embodiment of the invention can be carried out if the processing unit containing multiple interaction contexts is further characterized by the fact that the set of descriptions about the procedure comprises, as a mononym, a first description about the procedure that must be carried out in response to the primitive, or primitives, of communication that indicate one of the interaction contexts mentioned for later references in the processing unit accepting the communication primitive; This realization results in the appropriate activation of the indicated interaction context. The description of this context that activates the procedure can be used, obtaining beneficial results, to define the security requirements in relation to the selection of the context and to carry out the initiation of any security and operational data in the volatile part of the memory.

Another advantage that can be obtained with processing units that contain multiple interaction contexts characterized by the fact that the set of descriptions about the procedure comprises as a mononym one last description about the procedure that must be carried out in response to the primitive , or primitive, of communication that indicate one of the interaction contexts mentioned for later references in the processing unit accepting the communication primitive; This realization results in an appropriate deactivation of the interaction context that was indicated while the communication primitive was received. This deactivation procedure gives control to the application that was about to be replaced by the reception of the communication primitive. This gives the application designer the opportunity to run a memory content cleanup and terminate operations when the application crashes, which is unexpected.

In another preferred embodiment, the data exchange system defined above is characterized by the fact that the memory means also comprise, as a mononym, two interaction contexts, at least one description of the application and a memory element that stores a reference to the interaction context that was in effect at that time, so that each application description includes:

to. a list of data that includes references to the data elements, where two or more interaction contexts can access these references and that can be expanded with additional data elements;

b. another set of access conditions associated with said references or said additional data elements and that defines the restrictions of use.

By means of these measures, all interaction contexts can access all references to data elements that are common to different interaction contexts, so that they only need to be stored once, thus saving memory space. Also, the default interaction contexts can access the common access conditions to these data references. Thus, also these common access conditions only need to be stored once thereby saving memory space and enhancing efficiency.

Each description of the application can also include a library of procedures that includes codes that can use the descriptions about the procedure of each interaction context associated with each of the application descriptions mentioned.

Preferably, the processing unit is suitable for at least two applications and using little additional memory space. To achieve this objective, the data exchange system according to the invention is characterized by the fact that the memory medium comprises at least two application descriptions and some execution code units that can

ES 2 153 455 T3 can be used by means of descriptions about the procedure of each interaction context within each description of the application or by means of each unit of the execution code of each procedure library within each description of the application.

Preferably, the procedural library execution code units are completed by including a specification of the use of their operational parameters in classes related to the attributes that belong to the data elements that can be passed as real values ​​in a calculation, whose calculation only it is carried out if the attributes of the data and the parameter classes correspond. This is a very efficient way to check the access conditions both at the data level and at the level of operation for which there is a very efficient implementation.

Greater system reliability is offered if the data exchange system according to the invention is characterized by the fact that the execution program includes a reference in the case of a default interaction context and said reference is used to initialize the element. memory that stores a reference in the interaction context that is in effect at that moment, with the aim of carrying out a final action after the detection of an internal inconsistency when it recovers to a normal operating state or, provided that the execution program is active and no explicit interaction context has been specified by means of a communication primitive received from a similar data processing unit.

In order to continue improving the compactness of the implementation of the descriptions about the procedure, the procedure libraries, the code fragments and the execution program, the data exchange system according to the invention should be characterized by the fact that the execution program comprises programs that constitute an interpreter for the encoded instructions of an abstract processor, so that most of the descriptions about the procedure and some units of the code of execution are coded in numerical values ​​so that said programs of interpretation carry out the interpretations. In addition, the interpreter of the abstract code provided by the execution program helps in formally verifying the correctness of the implemented functions as the use of an abstractly designed set of instructions and a small number of implementation programs can make this Verification is more effective with the formal methods of reasoning and generation of evidence.

Still more advantageously with respect to the compactness of the storage of the descriptions of the interaction context and the descriptors of the application, the data exchange system according to the invention can be characterized by the fact that the descriptions about the procedure are encoded as if were ondic in a subset of procedures contained in the procedure library that includes units of the execution code. Specifically, in the context of the present invention, these management tables can be used to advantage since the number of different descriptions about the procedure depending on the nature of the structure of the data will generally be very small, e.g. For example, less than 16 so that the system can be further characterized by the fact that the coding of the descriptions about the procedure is given in such small values ​​that a basic access unit for the memory medium can contain more than one description or so that the description can be combined with other relevant information in the same base unit of the memory access. To face the unusual case in which the number of descriptions about the procedure within a single interaction context is greater than that which the coding space directly allows, a system implemented according to the present invention can advantageously employ an additional level of indirect reference so that it can be characterized by the fact that at least one of the coding values ​​of the descriptions about the procedure refers to a special function of the execution program that is designed to indirectly select the function real that must be executed to obtain the description about the coded procedure possibly by incorporating additional coded information stored in related to the description of the procedure encoded by these special values. Such additional compactness of data storage in the execution context data structure would be beneficial especially considering that one of the general requirements of the memory medium would be that it contain a considerable number of different applications and context descriptions. .

In order to increase the security of data and functions within the processing unit, The data exchange system according to the invention can be characterized by the fact that the memory medium includes an interaction context dedicated to understanding Personal Identification Numbers (PIN) and by the fact that the execution program is prepared to verify the Personal Identification Numbers established by a user of the data exchange system.

The Personal Identification Number management interaction context and the default context can be advantageously implemented as part of the same device support application. If used as a complement to this application on most of the devices with which a device communicates according to the invention, the owner of the device is offered the opportunity to review their private data in the form in which it was stored in the memory of the device. As a device, for example, a smart card holder could be allowed to modify its PIN at any terminal of the smart card that has an appropriate user interface.

Advantageous versatility in terms of elec5

ES 2 153 455 T3 tion of cryptographic protection methods that can be used to load the memory medium with data describing interaction contexts and applications can be offered within a data exchange system following the invention, characterized by the fact that the memory medium includes at least one interaction context dedicated to managing the number and content of other interaction contexts also contained in said memory medium. The market for portable processing units may establish a requirement that such versatility be offered with different degrees of security and operational complexity to load different applications on the same card as well as to establish a choice of different products with the objective of establishing organizations that are in all built will follow the same basic application infrastructure, as established according to the invention. Nowadays, solutions to this problem are rarely considered and are usually based on special proprietary functions implemented as an integral part of the execution program, so that they offer neither a uniform method nor a range of options.

Each application description can comprise a list of numeric values ​​that is built to provide identifiers to all interaction contexts and includes at least one of the following numeric values, the first indicates a type of application, the second numeric value indicates an identification the name of the entity that provides the application, the third numerical value indicates the nature of the application description and the rest of the numbers refer each one separately to an interaction context in relation to the application description.

The succession of numerical values ​​that refers only to an interaction context provides a means of establishing interoperability between two communication devices that is more efficient than is normally conceived for, eg. For example, smart cards by relegating to the application establishment entity the responsibility of assigning unique values ​​to each interaction context, while the assignment of unique numbers is the responsibility of the entities and the application corresponds to the relevant bodies of the sectorial cooperation and international respectively. The application establishment entity can beneficially assign unique context numbers to incorporate the implementation version and secret key generation information.

A data system according to the present invention can be implemented in such a way that it is characterized by the fact that the data communication means can be arranged to structure a data exchange in data blocks that include at least two parts, the first part corresponds to data classified as operational due to the fact that they are used to influence the nature of the operations carried out by a command as indicated by a communication primitive or data resulting from operations carried out, and the second part is called security because it is used to determine the appropriateness of executing an operation or if the data within the operational part is appropriate or not, to use them in the operation or to prove that the operation has been completed or that the resulting data is correct. Such provenance, acceptability, verification and correction is obtained by carrying out relevant cryptographic operations on the data.

This message structure in the data exchange and the order of the cryptographic calculations before and after carrying out the appropriate operational definition, provides a protection mechanism against attacks that interrupt the data exchange protocols. Specifically, it can be used to obviate the need to maintain a certain security state in the memory medium of each of the processing units since it can be exchanged as cryptographically encoded state information in each message contained in the part intended for security : The verification of the cryptographic condition in a secure way initializes the variable state that will need to be stored in the memory medium only until the response message is sent and not for any longer, reducing the time that said state information is exposed to attempts of manipulation. Finally, this message structure allows a more liberal use of complete security since communication security does not depend on any intervention or mediation device.

Authentication and data protection thus becomes an integral part of the execution of the order, establishing better security than that obtained in current systems, eg. eg on smart cards.

The execution program can be made to carry out, after accepting a communication primitive to perform specified operations in the current interaction context, each operation as part of a predetermined and fixed sequence of actions, each of which is specified separately. as part of a description of the procedure in relation to the accepted communication primitive, whose description of the procedure includes at least different descriptions, any of which may be null, for the following actions:

to. authorization of the use of the communication primitive;

b. decoding of operational data or any part of it;

c. execution of a command with the input data;

d. codification of any operational data resulting from any operation carried out;

and. calculation of a check that any action taken or carried out has been completed

ES 2 153 455 T3 checking the correctness of the resulting data to be used in the safety calculations.

Security is further increased if the data processing unit generates a random transaction number after initialization of the data transfer, which serves as the basis for cryptographic calculations.

To create the possibility of introducing a new interaction context if required, a communication primitive must be assigned to a specified value that will always be interpreted as a request to introduce a new interaction context.

In another preferred embodiment, The data exchange system according to the invention is characterized by the fact that it comprises another data processing unit that includes the same elements as the data processing unit that can optionally contain in its memory an application programming interface that can be used consists of programming code designed to allow additional computer programs to be implemented to give users control over the sequence of primitives of exchanged communication or to influence the data transferred in these or to learn or continue to process the data received in the exchange.

In a preferred embodiment of the invention such as this, the communication primitive that is used to introduce a specific interaction context may comprise numerical values ​​that will be used in security calculations in subsequent communications, the first value generated randomly or of a different nature. equally unique by one of the processing units and possibly the second value that serves to prove the authenticity of said processing unit or to otherwise identify said processing unit.

Another advantage of the present invention is that each communication primitive can be further structured so that it comprises two or more numerical values ​​that increase the expressive power of the communication primitive for interpretation by the execution program.

As a first alternative, each communication primitive, except the first one that indicates the restoration, can be composed of two or more numerical values, the first value is used to refer to a description of the procedure of an action in relation to the communication primitive. , the second value is composed of a fixed number of binary values, each of which is interpreted by the execution program as a reference to a single data element.

As a second alternative, each communication primitive, except the first one that signals the restoration, can be composed of two or more numerical values, the first value is used to refer to a description of the procedure of an action in relation to the communication primitive, the second value is used to determine which data element available to make external references in an active interaction context will be used while the response actions are being executed so that all data elements are selected if they contain a value that corresponds to that second value or if it contains a value that is otherwise sufficient to indicate it.

As a third alternative, each communication primitive, except the first one that signals the restoration, is composed of two or more numerical values, the first value is used to refer to the description about the procedure of an action in relation to the communication primitive , the second value is composed of two binary values ​​to which the execution program assigns specific meanings to be used in data interpretation format in the communication primitive and in the response actions executed.

The aforementioned portable processing units can be implemented in smart cards or in PCMCIA cards.

In another elaboration of the invention, the communication medium uses an external communication medium to establish a link between the data, such as the data processing unit that can access this external communication medium through the data processing unit, or similarly as electronic devices including electronic cards or PCMCIA cards that implement the data processing unit.

In an alternative of the invention, the data processing unit is implemented as a portable personal computer.

The media can use an electronic card reader or a PCMCIA card port.

In addition, the media can use, mainly or additionally, data transfers without contact with particles of electromagnetic fields.

The context mechanism defined above and the techniques it makes available lead to a broader scope of smart card usage and a smart card application development approach that has several advantages over traditional modes.

First of all, it allows the execution of a code of a specific program of the applications in a smart card without the need to examine the code in detail in the face of possible threats to the security of the data stored for other applications. As the access conditions that are stored with the data on the card are imposed by the card's operating system without the possibility of external interference during the execution of the application code, the scheme of the card with multiple applications does not need a programming code. that restricts their authority. This authority is the only way that makes a private code enforcement service possible on traditional smart cards. Through a code of approval on the execution in a card a restrictive authority acquires responsibilities with respect to the security of the global system; this makes the

ES 2 153 455 T3 management of electronic card schemes of multiple applications is much more complex. The associated complexity and costs make application-specific code in traditional card schematics nearly unattainable. With the new technique, it is possible to respond to the demand that has been given for some time for this service by providers of electronic card applications.

Secondly, as a direct consequence of specific application protection programs on cards, a specific application can be implemented that is dedicated to loading other applications on the card. In this way, applications, once loaded onto a card, can be protected from the same application that loaded them. This protection gives the parties involved in a multi-application card scheme, especially the entity that issues the card and the entities that provide the application, a basis for their business agreement. As it is based on tangible things such as the amount of storage required on each card, the number of cards to be equipped and the duration of the application on the card, rather than the abstract notion of "trustworthiness" and "good care ”, the application providers contract is easier to formulate than in traditionally implemented electronic cards. In addition, the card issuer and the application provider do not need to share the secret keys and protect the shared with contractual obligations and key transport services established by mutual agreement.

Third, if the application software is implemented based on the new technique, it has different advantages compared to previous electronic card operating system techniques:

* A minimal exchange of information is needed between a terminal and a card to establish interoperability between the card and the terminal, eg. eg, they support the same application (s). The data values ​​to be exchanged can be structured as proposed in the draft of the international standard ISO 7816-5;

* To complete a transaction between the card and the terminal, the monomer number of data exchanges that was inferred theoretically can actually be used, because the transaction is completed as a private calculation, instead of the need to use a long sequence of commands. standard, * Allows controlled access to data without requiring a related access path dictated by a directory and a hierarchy of files shared by all applications as commonly used and proposed to make it standard, * Allows development if the terminal and the application of the smart card go to headquarters, whose development process can be supported by computer software tools such as compilers and emulators. It can thus be achieved by elevating card and terminal software design and implementation above the tedious and error-prone language assembly coding currently required;

* Allows the standardization of equipment, both cards and terminals, using an abstract formalism to describe the capabilities of the device that gives flexibility to future developments, such as the new features offered by the card or terminal manufacturers. The standardized capability of the terminal could include an application programming interface. On the contrary, current efforts in favor of the standardization of electronic cards are concentrated on the prescription of fixed data content of messages to provide identification values ​​that must be interpreted in the way determined by the standard, which leaves little room for new developments.

Finally, with the new technique, implementers of smart card operating systems are given great freedom in designing the optimal implementations of the card operating system core and the terminal operating system. Electronic card hardware designers have different options to optimize the use of silicon chips with a hardware support for basic operations embedded in the core of the system. The reduction in hardware cost obtained by starting with the specialized design defined above may be greater than when it is based on general improvements over single chip computers.

The invention is now described in more detail with reference to some drawings showing an example of implementation of the general principles of the present invention.

Figure 1 shows an application design according to the previous technique of electronic cards based on a hierarchically organized collection of data elements;

Figure 2 presents a communication flow diagram between a portable processing unit and a similar processing unit in a format accepted today as standard.

Figure 3 presents a basic implementation of the present invention that uses the context of interaction in portable processing units, such as smart cards or PCMCIA cards, and more fixed processing units such as card terminals or portable personal computers;

Figure 4 presents an example of a practical organization of an execution context that highlights the different relationships between the descriptions about the procedure contained in the interaction context and the data elements and functions of the library used while they are being carried out. perform procedures;

Figure 5 shows an example of a pro8 run control flow chart

ES 2 153 455 T3 program and the security context triggers involved in the execution of the description on the procedure invoked by a communication primitive.

The structure of the data and the files in the systems of the prior art are illustrated in figure 1. Basically there is a master file 1 which is connected to different elementary files 3 and one or more dedicated files 2. Each dedicated file can be connected to one or more dedicated files 2 and to one or more elementary files 3. The preceding technique employed a tree hierarchy of directories and files. The number of subordinate levels in the structure of the preceding technique is, in principle, unlimited. The terminology used in figure 1 is taken from the international standard ISO 7816-4. Following the standard format for the communication flow between a portable data processing unit 5 and a similar data processing unit 4, as shown in figure 2, the communication comprises a set of pairs of blocks. The communication begins with a reset signal mφ from the data processing unit 4. Said reset signal may be outside the communication bandwidth as if it were generated by power over the logic in the data processing unit 5 but conceptually it is part of the orderly exchange of messages. The portable data processing unit 5 responds with a reset response (ATR) m1 possibly followed by contents. All the following pairs of blocks m2, m3, ..., m (n-1), mn consist of blocks headed by distinguished values ​​followed by contents and constitute different communication primitives.

Figure 3 shows the internal structure of two data processing units according to the invention that communicate with each other by transmitting and receiving data. The left data processing unit 4 can be, among other things, a terminal and the right data processing unit can be, among other things, a portable data processing unit, e.g. eg, a smart card. However, the invention is also applicable to two portable data processing units capable of communicating with each other via appropriate communication means or appropriate connection topology.

Each of the data processing units 4, 5 includes the data communication medium 7, 14 through which the structured blocks of data can be exchanged. Each of the data processing units includes the processing means 8, 15, and the memory means 9, 16. The memory means 9, 16 may be any configuration of read-only memory (ROM), random access memory (RAM) and read-only programmable memory, such as electronically removable read-only programmable memory (EEPROM).

The memory means 9, 16 includes an execution program 12, 17, indicated here by "MAXOS". If the portable data processing unit 5 is suitable for two or more applications, the memory means 9, 16 includes the application descriptions 13 (1) ... 13 (n), 18 (1) ... 18 ( n). There are as many application descriptions as there are data processing unit applications. Each application description is indicated by “CSA”. The second application description 13 (2), 18 (2) is shown on an enlarged scale in Figure 3 to allow the content of each application description to be displayed. Each application description 13 (i), 18 (i) includes at least one "interaction context" 11 (1) ... 11 (m), 19 (1) ... 19 (m). Each interaction context is indicated by "CTA". The first of these interaction contexts 11 (1), 19 (1) is displayed on an enlarged scale so that its content can be displayed. Each interaction context contains:

- a set of commands that specify the communication primitives recognized by the interaction context and that refer to the appropriate procedures specified in a set of procedures;

- a data set;

- a set of references to the data found in another interaction context, if there is one;

- a set of procedures that the execution program 12, 17 can carry out;

- a set of conditions for access to data elements;

- a set of external references that refer to the data elements to be used by the orders issued by the other data processing unit;

- optionally, other lists specified by the developer.

Finally, the memory means 9, 16 includes a memory element 21, 20 that contains a reference to the "current CTA", that is, to the interaction context in force at that moment.

The intention of different interaction contexts within an application description is to provide a functional separation in possible interactions between the data processing units 4, 5. This is especially relevant when the functional separation is also a separation with safety conditions. An example could constitute a first interaction between a smart card and a terminal to open, for example, a door and a second interaction when there are doors programmed so that they are allowed to be open. The second interaction requires greater security than the first interaction and is assigned its own interaction context. Gaining access to the interaction context is the first step in ensuring the security of the operations that can be executed within the interaction context.

IS 2 153 455 T3

Figure 4 shows a practical approach to the implementation of the context mechanism shown as a memory organization model that shows the relationships between data elements, access conditions and procedures. The structure of figure 4 applies as long as there are two or more applications of the portable data processing unit 5. If there is only one application, the structure is greatly simplified, as explained later. In figure 4 the reference numbers of the data processing unit 5 are represented. However, the structure of figure 4 can also be applied to the memory means 9 of the data processing unit 4. In Figure 4 the data element descriptions and procedure descriptions are optimally organized to reflect how the programming code and data are shared between the different interaction contexts (of the CTA) that create an application (CSA).

The memory medium 16 includes data elements H (1) ... H (7), execution code elements G (1) ... G (5) that are part of the operating system, and application descriptions 18 ( 1), 18 (2) (CSA1, CSA2). In Figure 4, the data and code found within the operating system are left out. The number of data elements, execution code elements and application descriptions as presented in figure 4 are only shown by means of an example: the numbers can vary as required in reality.

Each application description 18 (1), 18 (2) is found phosphically present in the memory medium. These provide a lower first level of abstraction that reflects the use of memory. Each application description 18 (1), 18 (2) consists of:

- a procedural library consisting of units of the execution code F (1) ... F (4) that can refer to elements of the code of the operating system available for this purpose, as indicated by the arrows P (1) ... P (5);

- a list of data elements E (1) ... E (7) for use by the procedures within the interaction contexts 19 (1) ... 19 (2) within the present application description 18. This data list includes the data access conditions and the indicators q (1) ... q (7) of the storage areas that include data elements;

- a list of the interaction context that includes several descriptions of the interaction context 19 (1), 19 (2).

The number of elements within the procedure library, the list of data elements and the list of the interaction context within the application description 18 (1) as shown in figure 4 is for the purpose of mere presentation only. Of course, the number of elements can vary depending on the desired application.

The content of the interaction contexts 19 (1), 19 (2) and the data structures of the application description 18 (1) in the processing units 4, 5 that take part in the data exchange is complemented in the meaning that the response of one unit is interpreted as a command by another unit. Through this supplemented nature, the encoded content, possibly in compact form, of the data structure can be generated from a single textual description. A data exchange system is generally made up of many implementations of processing units with a different purpose, which during the operation of the system can be contacted for a data exchange to fulfill this purpose. Each processing unit can only contain in its memory medium the part of the data structure that is relevant to the objective pursued by the system. The system as a whole is described through the collection of all the different contents of interaction contexts. In addition, some of the interaction contexts or part of their content can be loaded at any time if necessary. Said charging can be carried out safely, for example, by protecting it by applying the aforementioned management.

The interaction contexts 19 (1), 19 (2) are physically present in the memory medium that stores the application description 18 (1). Logically, interaction contexts provide a second layer of memory use control. The combined control provided by this second layer and the application description layer provide an efficient implementation of an execution context mechanism for portable data processing units, such as smart cards. Each interaction context 19 (1), 19 (2) includes:

- a list of descriptions about procedure C (1) ... C (5). Such descriptions of the procedure may refer to the descriptions of the procedure in the library of the procedure within Application Description 18 as indicated by the arrows in Example s (1). Alternatively these descriptions about the procedure can refer to elements of the execution code G (1) ... G (5) provided by the operating system, as indicated by the arrow in the example t (1). As another alternative, these descriptions about the procedure may contain explicit references to any data element that the procedure uses during execution and that is present in the data list of the application description 18 referenced, as indicated arrows r (1) ... r (6);

- a data list containing data elements B (1) ... B (5) only available to be used by the procedures in the context of interaction referred to. Data items are represented as references to the list of

ES 2 153 455 T3 data of the description of application 18 referred to with attached access conditions that must be adhered to when accessing the current data, as indicated by the arrows u (1) ... u (5 );

- a list of the external interface that includes the communication primitives A (1) ... A (4) that are accepted as commands by the corresponding interaction contexts 19 (1), 19 (2). Each command within a communication primitive refers to a member of the descriptions about the procedure C (1) ... C (5) from the list of procedures within the corresponding interaction context, as indicated by the arrows v (1) ... v (4). When the commands are given by the communication device 4, they can refer to the elements of the data list of the application description by one or more directions that follow the command. Each command can be accompanied by data items as input to command processing. The number of addresses as shown here is only as an example and is determined for each command as required in reality.

The protection of the data elements is established by determining the access conditions. Any external command within a communication primitive A (1) ... A (4) can only be directed to the data elements that have been referenced in the data list of the corresponding interaction context 19. Access is only allowed if the access conditions are met. These access conditions specify the type of conditions allowed to the command; This access condition may not be an access, a read-only access, a read and write access, and the use of a secret key. Other access conditions may also apply. For example, the communication primitive command A (1) can have only read access to the data element B (2) through the reference arrow w (2), while the primitive command communication A (2) has read and write access to the same data elements B (2) through the reference arrow w (3).

The descriptions about the procedure C (1) ... C (5) may refer to the data elements in the data list of the corresponding application description 18 and not to others. Again, access is only allowed if the access condition is met. These access conditions also specify the type of access allowed: for example, no access of the type of access only read, read and write access and use of secret keys. The access conditions for the different descriptions about the procedure within the same interaction context 19 may be different for the same element of the data list of the application description E (1) ... E (7), p. For example, the reference arrow r (1) can represent a read-only access condition, while the reference arrow r (2) can represent a read and write access condition.

The access conditions are checked at the relevant level, that is, at the level of the application description or at the level of the interaction context and only once. An element B (1) ... B (5) of the data list within an interaction context 19 (1), 19 (2) is directly referenced by the arrow u (1) ... u (5) to the data element indicator in the data list of application description 18 (1) because the access conditions are already met in the data list element E (1) ... E (7 ) of application description 18 (1). However, the descriptions about procedure C (1) ... C (5) within an interaction context 19 (1), 19 (2) that refer to elements of the data list within the application description 18 (1), must first meet the access condition in relation to with the data list elements E (1) ... E (7) within application description 18 (1). You cannot refer to any data element or description element about the procedure within the application data lists 18 (1) and their associated interaction contexts 19 (1), 19 (2) by any other application description. within memory medium 16. The code of execution that constitutes the description of the procedure can only be addressed to the data indirectly through the restricted set of references to the data in relation to each description of the procedure C (1) ... C (5). Using the data elements described by B (1) ... B (5), the reference list is temporarily extended by the execution program with the references to the data item as obtained by evaluating the addresses that are actually specified in the communication message accepted as the command associated with the description of the procedure. In this way, you cannot access any data other than that explicitly specified, and only in compliance with the specific conditions of use. That is, the preferred memory reference model of Figure 4 with regard to the application description with its associated interaction contexts provides a unique context for operations within a single application of the data processing unit 5. The data elements H (1) ... H (7) are stored in memory medium 16 common to all applications but containing the data for their exclusive use within the context of application description 18 (1), this exclusivity is guaranteed by the execution program by allowing the existence of a single indicator of each storage location as q (1) from E (1) to H (2). Only one can refer to the elements of the code G (1) ... G (5) by means of any of the application descriptions 18 (1) ... stored within the memory medium 16. These last references of other application descriptions different from those made by the application description 18 (1) to the codes Common G (1) ... G (5) are not explicitly indicated in figure 4. However, any person skilled in the art can easily extend the structure of figure 4 to two or more application descriptions 18 (1), 18 (2), ....

IS 2 153 455 T3

Having explained how data items can be protected by using access conditions of different types, the resources for memory management will now be explained. When it comes to managing memory, you want tamper data (data items) and hard data (operating system code) to be managed separately by the operating system. The memory reference model as shown in Figure 4 establishes a separation between the code and the data elements within the memory medium 16 referred to by the indicators q (1) ... q (7) , p (1) ... p (5) from the data list and the procedure library, respectively, within the corresponding application description 18. The elements of the data list within each interaction context 19 (1), 19 (2) only contain references to these indicators and do not contain direct references to the codes G (1) ... G (5), nor to the data elements H (1) ... H (7) within the memory medium 16. The data list of the corresponding application description 18 establishes the level of deviation required by the operating system to carry out the management of the memory.

Code duplication is avoided by establishing common code libraries at two levels: "command bodies" such as the description on procedure C (3) that refers to the code element F (2) in the procedure library in the description of application 18 (1) with the aim of sharing common codes between the different contexts. However, the body of the description on procedure C (3) also directly refers to a code G (3) stored in memory medium 16 and provided by the operating system. All elements of the code G (1) ... G (5) provided by the operating system are implemented to achieve efficient execution.

Reference to code elements F (1) F (2) can be made with a memory address or with additional levels of deviation with indexes in appropriately constructed tables. The hierarchical structure of the references established here is very suitable for an implementation with indexes like this one.

Fundamentally, the memory structure according to figure 4 can also be applied in situations where only one application of data processing unit 5 is established. In this case, only application description 18 (1) can even match with an interaction context 19 (1), whose interaction context then contains the following coherent set of definitions:

to. a set of basic communication primitives A (1) ... that are accepted as long as the data processing unit 5 communicates with a similar unit 4, said primitives include at least one primitive that is used to introduce at least one of said contexts of interaction;

b. a set of descriptions about the procedure C (1) ... that defines the actions to be executed in response to each of the accepted communication primitives

A (1) .... including at least a first description of the procedure to be executed after the activation of the interaction context, and a last description of the procedure to be executed immediately before deactivating the context;

c. a possibly empty set of data elements H (1) ... either permanently stored or computed, which is available for use when carrying out the procedures as defined in the descriptions of the procedure C ( 1) ...;

d. a possibly empty set of references to data elements, the references of which are associated with the descriptions about procedure C (1) ... other possible interaction contexts can access said data elements and are available for use when the procedures are carried out as defined in the descriptions about procedure C (1) ...;

and. a list of data, possibly empty, that includes a list of references to the data elements that are available for explicit reference as part of a communication primitive to be used by the description about the procedure in association with the primitive of communication;

F. a set of access conditions in association with the data elements referred to in association with the descriptions about the procedure;

g. a set of access conditions in relation to the reference list of data B (1) ... in the data list.

If only one application is provided for data processing unit 5 and there are at least two interaction contexts 19 (1), 19 (2), each application description comprises:

to. a data list including references E (1) ... to the data elements, the references of which can be accessed by two or more interaction contexts 19 (1) ... and can be extended by additional data elements;

b. another set of access conditions in relation to said E (1) ... references or to said additional data elements and descriptive restrictions on use.

The set of descriptions about the procedure in each of the two or more descriptions of the interaction context also contains a

ES 2 153 455 T3 is the last description of the additional procedure to be carried out immediately before deactivating the context.

Figure 5 represents the control flow in the execution program defined above by "MAXOS" (12,17).

After powering on the system, the software begins processing a reset code in step 30. In step 31, the security level of the core operations of the data processing unit is entered. The access conditions that describe this level are stored in a part of memory that cannot be modified, eg. For example, in hardware ROM. In step 32, non-volatile memory is checked for consistency and any modifications that may have been left incomplete due to being turned off unexpectedly are canceled, e.g. eg, by removing a smart card. The non-volatile memory consistency check only involves examining the information stored in memory and calculating the sums of the checks. The contents of the memory, if it can be accessed, is only used to calculate the checksums. Thus, the consistency check is a safe operation. The exact nature of the consistency check components depends on hardware details within the data processing unit and non-volatile memory modification programs that are largely irrelevant to the specified security architecture. After the general memory consistency check, the previously calculated levels of the security context stored in memory are verified. Finally, the random access memory of the data processing unit is indicated.

In step 33, if the runtime environment is declared secure in this way, the security level of the secure application of the data processing unit is entered. At this level all accesses to the memory belonging to the operations of the nucleus are blocked. The access to the application data and the description of this level is only achieved through programs in the core that maintain the state information in continuous memory operations.

After the first entry after the reset, in step 34 the application element data descriptors are used to control the consistency of the data stored in the descriptor and memory is changed if it is in an inconsistent state with an attribute such as the one described. A response to reset (ATR) message is composed of application identifiers stored in the application descriptors and is completed with a transaction number calculated so that the other data processing unit 4 that receives them cannot predict it. . Inside the data processing unit, a command is generated from a terminal to activate a default interaction context. Directly after the ATR message is sent to the other data processing unit 4 this internal context activation command is executed to provide an interaction context for subsequent commands. The ATR message clearly indicates the readiness of the data processing unit to accept other commands. The default interaction context can be designed as part of an "application containing a smart card" that is present as a standard application on all multi-application smart cards. In this specific application context, the user, specifically the smart card holder, can review their personal data or open any of the other applications on the card.

In step 35, as a result of the context activation command, the security level of the interaction context (CTA) for the support of the standard CTA smart card is entered.

After it has been fully activated, the application is ready to receive orders from the other data processing unit. Other processing depends on the command received: a command to activate an application is handled differently than a command to be executed. Consequently, in step 38, after having established that a communication primitive is received in step 36 and that this is considered acceptable in step 37, it was evaluated whether a new application has to be activated. If not, step 39 is entered in which the command is checked to determine if the input data is allowed and if it can be accepted. These verifications are carried out only for a command if it was specified or even in the application descriptor. A decoding of the input data can also be carried out in step 39.

If the test is successful, the "data access protection level" is entered, step 40. At this level, the highest security level, you can run the programs that are coded by the application providers, step 41. Such programs are stored in the application descriptor and function as a specific reaction to the application to a specific command issued by the other data processing unit 4. This level of security restricts memory conditions to a subset specifically defined for the command that was being executed.

After carrying out the command with the input data set in step 41, the data access protection level is left, step 42.

The output data and the verification (cryptographic) that the command has been completed are generated in step 43. A function like this is only carried out for a command if it was specified in that way in the description about the procedure, which it can be null for any action of composition of the definition. After step 43, the program waits for the new communication primitives, step 36.

If no special command program is defined and the command can be executed by procedures consisting only of operating system functions, the data access protection level is not entered.

ES 2 153 455 T3 (step 40), and the command will be carried out at the security level of the interaction context directly as the operating system programs are designed in such a way that they do not violate any data protection.

If, in step 38, it is set that no new applications are activated, the program proceeds to step 44 in which a context deactivation procedure is carried out. In step 45 the specific security level of the current application is abandoned and, in step 46, the security level of the data accompanying the command of the execution program "MAXOS" is checked.

If the command is allowed through appropriate authentication as specified for the requested application, a CTA security level is entered for the new application, step 47. This level restricts access to data pertaining to the newly opened application. .

The data processing unit produces data in response to the context activation command by executing an initialization instruction as defined in the procedure list, step 48. If a coded program from the application supplier is presented as this, it is entered the level of data access protection in step 49. The context activation procedure is carried out in step 50. In step 51 the data access protection level is left and the data processing unit communicated with the other 4 and the data processing unit 4 itself is ready to receive a new command after step 43, specified above.

After having described Figures 1 to 5, some general comments are now made about the data exchange system following the invention.

The procedure library codes within each 18 (1), 18 (2) application description can be increased by including a specification on the use of their operational parameters in classes relating to the attributes that belong to the data elements that can be introduced as real values ​​in a calculation, whose computation only proceeds if the attributes of the data and the classes of parameters correspond. This provides a way to verify the access conditions for both data items and functions. Comparing properly coded bitmaps of the data attributes and parameter classes respectively can provide an efficient implementation for this additional technique.

The execution program 12, 17 may include a reference to an interaction context that is used to initiate the current interaction context in memory element 20 by storing a reference to the interaction context that is in effect at that time. By means of this measure it is possible to carry out a final action after the detection of an internal inconsistency in the recovery until reaching a normal operating state or whenever the execution program 12, 17 is activated and a communication primitive received from the other unit data processing 5 has not specified any explicit interaction context. This default interaction context may well be a context contained in the card carrier application as described above.

Additionally, the memory means 9, 16 can comprise an interaction context 11, 19 dedicated to understanding personal identification numbers (PIN) and it is established that the execution program 12, 17 verifies the personal identification numbers established by a user of the data exchange system. Different personal identification numbers, passwords, like these can be used. A password like this can be used to protect the use of the device in those transactions in which confidential data could be revealed. A second password can be used to protect transactions in which data representing a payable value is reported via a password. A third password can be used to protect the transactions in which operations supposedly critical for the security of the application are carried out, such as the protection modes of the previously specific calls within each of the interaction contexts 18 that may need it. Other passwords can be set. This context of interaction of the PIN management could well be a context contained in the application of the card support as described above.

Each application description 13, 18 can comprise a list of numeric values ​​created to provide identifiers for all interaction contexts 11, 19 and each application description 13, 18 can comprise a combination of any first numeric value that indicates an application type. , a second numerical value that indicates a unique identification of the entity that establishes the application, a third numerical value that indicates the nature of the application description 13, 18 and other numbers each referring only to an interaction context 11, 19. The first two numbers can be assigned following well established rules in the trade, while the rest of the numbers can be chosen by the entity supplying the application as deemed appropriate. In particular, numerical values ​​can be assigned to distinguish between different versions of an implementation or to identify the generation of the set of cryptographic keys used by the application in its cryptographic calculations. Additionally, the device can include in the reset response message a list for each of the application contexts 11, 19 that contains in its memory means an identification number composed of unique identification values ​​stored in the interaction context. . The first item in the list of interaction context identification numbers can be an identification for the default context.

The data communication means 7, 14 are preferably arranged so as to structure a data exchange in data blocks. These data blocks comprise at least two parts, a first part made up of

ES 2 153 455 T3 data qualified as operational due to the fact that they are used to influence the nature of the operations carried out by a command as indicated by a communication primitive or qualified as data resulting from operations carried out. The second part will be qualified as security by the fact that it is used to determine whether it is appropriate to execute an operation or to determine the acceptability of the data within the operational part to be used in the operation or to verify that the operation has been completed. or to check the correctness of the disclosed data.

When the data is structured in this way, the execution program 17 can be prepared to execute, after accepting a communication primitive to carry out the specified operations in the current interaction context 20, 21, each operation as part of a sequence default and fixed stock, each of which is specified separately as part of a procedure description rule in association with the accepted communication primitive. A first action can be specified as a function to authorize the use of the communication primitive at this point in the communication sequence. A second action can be specified as the function to decode the operational data or any part of it, while a third action can be specified as the appropriate operational procedure. A fourth part can be specified to encode any operational data resulting from the executed operations and a fifth action can be specified as the function to obtain proof that the executed action has been completed or a proof of the correctness of the resulting data or for use them in security calculations in the receiving unit for data processing. These actions are reflected in the flow chart in Figure 5.

Additionally, the data processing unit 5 includes in its reset response message a number chosen so that the receiving data processing unit 4 cannot predict its value and which can serve as a basis for cryptographic calculations. Said number can be designated as the "card transaction number".

A communication primitive will be set assigned to a specific value that will always be interpreted as a request to introduce a new interaction context 11, 19. This communication primitive can be designated as the "activation command". The data attached to the activate command sufficiently specifies the context to be activated possibly by referring to the identification numbers communicated as a part of the reset response message. The actions executed when responding to the activation command are described first by means of the description of the procedure contained in the context, accepting the designated primitive regarding deactivation and, secondly, described in the description of the procedure. designated for the activation contained in the specified context to introduce it.

Preferably, the communication primitive used to introduce a specified interaction context 11, 19 comprises numerical values ​​to be used in the security calculations in subsequent communications. A first value can be created randomly by one of the processing units and a second value can be used to identify that processing unit. Said value can be calculated in different ways according to the requirements of the cryptographic protocol used, said difference can be specified as part of the description of the C1 procedure. This identification may be the result of calculations that are presented in such a way that the resulting value sufficiently identifies the device and that the status of its memory is activated, as required by the calculations or other actions that may be executed in subsequent data exchanges in the interaction context 11, 19. Said second value can be designated as "terminal identification".

Additionally, the activation command provides, as part of the resulting data, a numerical value that serves to identify the specific data processing unit that responds sufficiently to what is required by the calculations or other actions that can be executed in subsequent data exchanges. in the context that has just been activated, whose number can be designated as "smart card identification".

Likewise, the identification of the smart card number can be calculated using cryptographic functions from the data stored in the data processing unit5 or from the data received as part of the activation command in such a way that the number varies unpredictably when calculated in response to the commands. activation commands received from startup devices with different terminal identification numbers; a smart card identification calculated in this way may be designated as a "smart card pseudonym". Furthermore, before executing the actions described in the description about the procedure of the activation procedure of a context to be entered, the execution program can carry out a cryptographic calculation specified as a description about the procedure in that context designated for to be carried out after activation to determine if the context can be activated. The calculations may involve the use of the smart card identification transaction, the terminal transaction identification and the terminal identification and other values ​​stored in the memory medium.

As an alternative to these cryptographic protocols that are supported by specific data in the activation commands, commands can be used with a specification about the bit fields of the referenced data elements. In that case, each communication primitive is made up of two or more numerical values, the first value

ES 2 153 455 T3 is used to refer to a description of the procedure of an action associated with the communication primitive, the second value is composed of a fixed number of binary values, each of which is interpreted by the execution program 12, 17 as a reference to a single data item. This data element is specified in the reference list of the external data in the corresponding interaction context 11, 19, each data element of the list is specified by the presence of a binary value of one of the binary numbers in a position corresponding in the list of binary values. This second value can be designated as "operant addresses". The operational execution program 12, 17 makes available each of the data elements that are specified as well so that they can be used in the response action as they are described in the description of the procedure of said action.

As an alternative to the cryptographic protocols and to the commands with specification of the bit field of data elements referred to, a command format can be applied with a specification of the data connection of the data elements. In this case, each communication primitive is composed of two or more numerical values, the first value is used to refer to a description of the procedure of an action associated with the communication primitive, the second value is used to determine which element of data available for external references in an active interaction context 12, 19 It was used while executing response actions so that any data item is selected if it contains a value that corresponds to that second value. This second value can be designated as the "operant terminal specifier". Additionally, the interaction context 11, 19 may contain a description about the procedure that indicates how a specifier of the operant terminal given as part of a command is to be compared with the data contained in any of the data elements available for reference. external in that context, whose description on the procedure is carried out to select the data elements that are desired before the description on the procedure is executed specifying the actions of the command in an appropriate way.

Alternatively, you can use a command format specifying the bit field of the command interpretation. In this case, each communication primitive is composed of two or more numerical values, the first value is used to refer to a description of the procedure of an action associated with the communication primitive, the second value is composed of two binary values ​​a those that are assigned a specific meaning through the execution program 12, 17 to be used in the data formats for interpretation in the communication primitive and to execute response actions. Here the second value can be designated as "command modifier". Values ​​are recognized for their assigned meaning by all units equipped with this additional technique.

In case the last alternative applies, the command modifier can include a binary value that determines whether a third part of the command is to be used as an operant address or as an operant terminal specifier. However, the command modifier can alternatively include a binary value that determines whether the operation performed in response to the command used data as the data element or whether it would be composed of a chain of data elements that were to be used. processed in conjunction with each data item specified as part of the command value using operant addresses or an operant terminal specifier. Alternatively, the command modifier may include a binary value that determines whether the data set with the command is encoded using the terminal length value method to discriminate successively chained data items.

Another option is that the command modifier can include a binary value that determines whether executing the action suggested by the command will actually lead to an effective change of the data stored in data processing unit 5 (smart card) or will actually damage as a result data calculated by the data processing unit 5, or that the result of the command is data that reflects the state of the unit regarding the acceptability of the command, the data that accompanies it, the size of the data that could result from calculations or other diverse attributes.

In summary, the new technique introduced above in electronic card implementation is the concept of a separate execution environment. In this approach, the processing means and other sources of a computer are shared between the different applications as if the application were the only user of the computer. If this new technique of electronic card implementations continues, a mechanism is established to define the multiple access conditions to the data shared by various related applications. A second technique that is supported by the separate execution environments introduced above consists of the possibility of defining the functional meaning of the commands in each environment to obtain a mononymous number of commands in each interaction between two similar data processing units. 4, 5 within a data exchange system. Finally, it is possible with the new technique to introduce the names that refer to the data elements stored within each context separately. The reference to the data elements stored as part of a command received from one of the data processing units 4, 5 can thus become very efficient: due to the small number of data elements and the small number of defined operations that are performed. used in today's smart cards, the separate practice in each environment only needs a few bits to encode the name and space of the instruction. In a few conditions

ES 2 153 455 T3 of access in a similar way, the methods of verification of this and the cryptographic operations available for that purpose in real smart cards would be very restricted in numbers and can be expressed very efficiently in a hierarchy of two layers of data. descriptions of the interaction context 19 (1) ... included in the application description 18.