HK1070967A - Data exchange system comprising portable data processing units - Google Patents

Description

Data exchange system comprising a portable data processing unit

The application is a divisional application of Chinese patent application with the application date of 1996, 8/2/8, the application number of 96196785.4, and the invention name of "data exchange system including portable data processing unit".

Technical Field

The invention relates to a data exchange system comprising a plurality of data processing units, wherein some portable data processing units establish temporary communication links with one or more other units in the system, and other units which are not moving may have permanent communication links with one or more other units in the system. These processing units include data communication means, processing means and storage means, the latter containing the execution programs.

Background

Such A system is known from international patent application WO-A-87/07063, in which A system for A portable datA carrier with A plurality of application files is described. One of the most important applications of such a portable data carrier is a smart card (smart card) which is suitable for a large variety of applications. The known data carrier is described as a carrier with security features to support hierarchically structured data of a plurality of applications on the data carrier. The application is considered as a data set. The present patent application describes implementing a hierarchical file system on a data carrier for storing alterable data in conjunction with a hierarchical set of access permissions. The data carrier is responsive to a common set of commands. File access permissions differ from operation to operation and rely on verification of passwords for authorization. A password verification attempt counter is introduced as well as setting stored data corruption to prevent too many access attempts. The known data carrier is provided primarily as a storage means and not as a processor. The executive can only perform very simple functions such as binary logic operations. It is not possible to allow an unspecified set of operations to be performed upon request of a terminal communicating with the data carrier. The only security option is to introduce password verification. In the known system no further access condition check is possible. Furthermore, each application of the data carrier has its own file in the storage means of the data carrier. No special measures are taken to increase the efficiency of the available memory space, which is very limited especially on smart cards and thus limits the number of possible applications.

EP- ｃA-0,479,655 relates to the implementation of access condition checking in smart cards. One specification technique for this purpose is disclosed, however, it is desirable to provide measures that include the possibility of other access condition checks.

EP- ｃA-0,361,491 relates to ｃA chip card programming system allowing protected (re) programming of cards. It describes the use of write-once access conditions to control access to a portion of a programmable memory to be programmed. In this way the number of applications on a single card can be increased. Access condition checking using various techniques, including cryptographic protocols, is described.

EP- ｃA-0,292,248 relates to loading applications on ｃA smart card using ｃA non-modifiable operating system program. It includes the implementation of a data access conditional enforcement method using memory areas with specified access attributes. The specific access conditions are "write once" (implicitly described only) and "execute only".

US-A-4,874,935 relates to card programming employing A datA dictionary that describes an arrangement of datA elements stored in A memory of A card. A data dictionary is generally understood to be different from a directory in that the data dictionary describes not only data actually stored but also data to be stored later. In addition, data dictionaries typically contain a description of the format of the data. Compiled format data dictionaries are used in database management systems and are stored on hard disks as part of the database. They may also be found in the software development environment in a target load file derived from the compilation of programs. However, this patent does not suggest a description of a data dictionary particularly suitable for smart cards.

EP0466969a1 relates to providing functions in the execution of a program by a smart card to support the correct transfer of a sequence of messages between the smart card and a terminal by reserving a portion of the card's memory as state information storage and providing specific means to implement a state machine that controls state transitions. This state information is crucial in determining the actions to be performed when a message is received. State machines that accept variable sequence messages are well known in computer language compiler design and computational complexity theory. The patent does not suggest the possibility of implementing a variable set of possible actions specific to several possible applications residing simultaneously in the smart card.

Disclosure of Invention

The main object of the present invention is to provide means for formally, accurately and uniquely describing a system consisting of credit processing units (trusted processing units) in such a way that they will function when communicating between them, wherein such communication is intended to convey values or other credit information. This comprehensive description of possible communication modes between the data processing units applies both to the system as a whole and to the detailed operation of the individual processing units. This formal description provides the basis for formal reasoning in the correctness verification of the implementation, which would be necessary for the worldwide deployment of the system.

It is a further object of the present invention to provide means for optimally overcoming the limitations imposed by the limited physical size of the available storage space on portable data processing units, especially smart cards.

It is a further object of the invention to provide a more versatile mechanism for protected loading of program code and to allow such loading to be used for a plurality of programs, each program for one application of a respective portable data processing unit.

Furthermore, the present invention is directed to the use of access condition verification that is not specified by the manufacturer of the portable processing unit, but is selected by the application designer to suit its particular needs.

The present invention is also directed to providing a mechanism to protect communications between processing units so that content and ordered sequences cannot be disturbed by any intervening devices.

The system according to the invention is therefore designed with the features of claim 1.

By organizing the description of a system for credit processing unit communication in this strict framework, the operating conditions and effects of possible communications between devices are fully and exhaustively described. After being augmented with a formal and precise semantic definition of the structural elements, the data becomes amenable to formal reasoning and thus the implementation of the present system becomes more suitable for formal checking of correctness. For this purpose, it is not necessary that all data reside in all memory devices of a single processing unit. It is sufficient to load the data into the processing unit before using it. Secure loading of data is encompassed by the present invention.

In a first preferred embodiment, the individual processing units in the data exchange system are designed with the features of independent claim 2.

As indicated above, the present invention aims to generalize the concept already claimed in prior art EP-A-0,666,550 according to Art.54(3) EPC. The claimed protection of EP-A-0,666,550 is defined as follows:

data exchange system comprising at least one portable data processing unit (5), said unit (5) comprising data communication means (14), processing means (15) and storage means (16), the latter comprising an executive program (17), characterised in that the storage means (16) further comprises at least one interaction context (19(1) … 19(m)) comprising the following associated data structures:

a. a set of elementary communication primitives (a (1) …) to be received each time a data processing unit (5) communicates with a similar unit (4), said primitives including at least one primitive for selectively entering one of said interaction contexts (19(1) …);

b. a set of process descriptions (C (1) …) defining actions to be performed in response to each received communication primitive (a (1) …), including at least a first process description to be performed when an interaction context is activated, and a last process description to be performed immediately before the context is deactivated:

c. a set of possibly empty data elements (H (1) …) that are either permanently stored or calculated and which are available for use when executing the procedure defined in the procedure description (C (1) …);

d. a set of possibly empty references to data elements associated with the process description (C (1) …), said data elements being accessible also to possible other interaction contexts and being available for use when executing the process defined in the process description (C (1) …);

e. a data table, possibly empty, containing a table of references (B (1) …) to data elements that are available for explicit reference as part of the communication primitive (a (1) …) used by the process description (C (1) …) associated with the communication primitive;

f. a set of access conditions associated with a data element, the data element referenced in conjunction with a process description (C (1) …);

g. a set of access conditions associated with a table of data references (B (1) …) in the data table.

Which is explicitly disclaimed from the scope of protection claimed in the present independent claims 1 and 2.

By defining the data within the storage means of the portable processing unit in this way, the processing unit is in fact organized as a processor, i.e. it not only allows additions and subtractions, but also performs the processing procedures loaded in the processing unit by authorised personnel, such as bank staff. By providing a process that can provide arbitrarily complex operations in response to received commands, and providing an explicit table of stored data elements that can be addressed as part of these commands, optimal use of communication bandwidth can be achieved; resulting in a reduction in the number of commands exchanged. Many practical uses of the system according to the invention require only two commands to be exchanged. The only fixed thing is the structure within the storage device, which is defined such that several applications of the unit can be added in a very efficient way, i.e. by utilizing as little additional storage space as possible. This is especially important if the unit is a smart card that is severely limited by the available storage space. Furthermore, 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 which they do not have access to.

An advantageous embodiment of the invention can be realized if the processing unit comprising a plurality of interaction contexts is further characterized by the following points: the set of process descriptions comprises at least a first process description executed in response to the communication protocode, which indicates one of the interaction contexts for further reference in the processing unit accepting the communication protocode, which execution results in a correct activation of the indicated interaction context. This description of the context activation process can advantageously be used to define security requirements associated with the selection context and to perform initialization of any security and operational data in the volatile portion of the storage device.

Further advantages are obtained by a processing unit comprising a plurality of interaction contexts characterized by the following points: the set of process descriptions includes at least a final process description executed in response to the communication protocode, which indicates one of the interaction contexts for further reference in the processing unit that accepted the communication protocode, the execution resulting in a correct deactivation of the indicated interaction context upon reception of the communication protocode. This deactivation process gives control to the application that is to take over by accepting the communication scrambling code. This gives application designers the opportunity to perform memory content cleanup and finish operations when an application is unexpectedly suspended.

In another preferred embodiment, the data exchange system defined above is characterized in that: the storage means further comprises at least two interaction contexts, at least one application describing and storing a memory element referencing the interaction context currently being implemented, each application description comprising:

a. a data table containing references to data elements, the references being accessible by two or more interaction contexts and extensible by additional data elements;

b. another set of access conditions associated with the reference or the additional data element and defining a usage restriction.

By these measures all references to data elements common to different interaction contexts are accessible to all these interaction contexts, so they need only be stored once, thus saving storage space. And the common access condition to the data references is also accessible to the predetermined interaction context. Therefore, these common access conditions also need to be stored only once, thereby saving storage space and increasing efficiency.

Each application description may also include a library of procedures that contain code that may be used by the procedure descriptions of the interaction contexts associated with each of the application descriptions.

Preferably, the processing unit is adapted for at least two applications using only a small amount of additional memory space. To achieve this object, the data switching system according to the invention is characterized in that: the storage means comprises at least two application descriptions and execution code units usable by the process descriptions of the interaction contexts within the application descriptions or the execution code units of the process libraries within the application descriptions.

Preferably, the executing code elements in the process library can be enhanced by including descriptions of their operating parameters with categories related to attributes of the data elements communicated as actual values in the calculations that can only be performed if the data attributes match the categories of the parameters. This is an efficient way of access condition checking at the data level and at the functional level, for which there exists a very efficient implementation.

The data exchange system according to the invention offers greater reliability if it has the following features: the execution program includes a reference to a default interaction context for initializing the memory unit storing the reference to the interaction context currently being implemented, in order to perform a final action after detecting an internal incompatibility in reverting to the normal state of operation, or whenever the execution program is started but no explicit interaction context has been specified by the communication primitive received from a similar data processing unit.

In order to further increase the compactness of the implementation of the process description, the process library, the code fragments and the executive, the data exchange system according to the invention may be characterized in that: the executive includes routines that make up an interpreter of coded instructions for the abstract processor, such that most of the process descriptions and some of the execution code units are coded as numerical values for interpretation by the interpreter routines. In addition to the execution of a program-provided abstract code interpreter to assist in formal verification of the correctness of the implemented functionality, the use of an abstracted designed instruction set and a small number of small implementation routines may also make such verification better suited for use in the formal methods of inference and proof generation.

With the further advantage of compactness regarding the storage of interaction context descriptions and application descriptors, the data exchange system according to the invention may be characterized in that: the procedure description is encoded as an index into a table on a subset of procedures contained in a procedure library consisting of execution code units. In particular in the context of the current invention, these schedules may be configured with the advantage that, due to the nature of the data structure, the number of individual process descriptions is typically very small, for example less than 16, so that the present system may further have the following features: the encoding of the process descriptions is of such a small value that more than one description can be stored in one basic access unit of the storage device, or the descriptions can be combined with other related information in the same memory access basic unit. In order to solve the rare case that the number of process descriptions within a single interaction context is greater than the number directly allowed by the coding space, the system implemented according to the invention can advantageously employ an additional level of indirect referencing, so that it is characterized in that: at least one coded value of the process description accesses a special function of the executive program, which special function is designed to indirectly select for the coded process description the actually executed function by adding additional coded information stored in connection with the process description coded with said special value. This additional storage compactness of the data in the context data structure is advantageous, especially in view of the storage devices typically need to store 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 may comprise the following features: the memory device includes an interaction context dedicated to containing a personal identification number, and the executive is configured to verify the personal identification number provided by a user of the data exchange system.

Advantageously, the pin management interaction context and the default context may be implemented as part of the same device holder application: the support of this application by most devices with which the device according to the invention communicates gives the device owner the opportunity to observe his personal data stored in the device memory, for example to allow the holder of a smart card to modify his PIN on any smart card terminal providing a suitable user interface.

The advantageous versatility of the choice of cryptographic protection methods for loading storage means with data describing the interaction context and applications can be provided in a data exchange system according to the invention with the following features: the storage means comprise at least one number and interaction context dedicated to managing other interaction contexts simultaneously contained in said storage means. The market may require the provision of a generic portable processing unit with different levels of security and computational complexity in order to load different applications on the same card and to build different product options for card issuing organizations, all built according to the same basic application internal structure, such as that provided by the present invention. Few solutions to this problem exist today and are generally based on appropriate special functions implemented as an integral part of the executing program, providing neither a uniform approach nor a range of options.

Each application description may contain a table of values constructed to provide identifiers for all interaction contexts and including at least one of the following values: a first value indicating the type of application, a second value indicating the unique identity of the entity providing the application, a third value indicating the nature of the application description and further numbers each uniquely referencing an interaction context associated with the application description.

A string of values uniquely referencing an interaction context provides a means of establishing interoperability between two communication devices, which is more efficient than transferring the responsibility for assigning a unique value to each interaction context currently envisaged for example for smart cards to the entity supplying the application, while leaving the responsibility for assigning unique numbers to the entity and the application, respectively, to the relevant regional and international corporate communities. The entity provisioning the application can advantageously assign a unique context number to join the implementation version and the secret key generation information.

The data system according to the invention may be implemented such that the data communication means may be arranged to constitute a data exchange with a data block comprising at least two parts, a first part being operational data with which the nature of the operation performed by the command indicated by the communication primitive is influenced or data derived from the operation performed, and a second part being security data with which the appropriateness of performing the operation or the acceptability of the data within the operational part is determined for use in the operation or to prove the correctness of the data upon completion or derivation of the operation. These appropriateness, acceptability, proof, and correctness are derived by performing a related cryptographic operation on the data.

This message structure in the data exchange and the order of cryptographic calculations before and after the appropriate operation definition is performed provides a mechanism for protecting against intermediate attacks on the protocols of the data exchange. In particular, it can be used to eliminate the requirement for explicitly maintaining a secure state in the storage means of each processing unit, since it allows the data contained in each message in the portion specifying security to be exchanged as cryptographically encoded state information: verifying the encryption conditions securely initializes state variables that need only be stored in the storage until a reply message is sent, reducing the time that such state information is exposed to a tampering attempt. Finally, this message structure allows a more liberal use of end-to-end security, where security in communication is not dependent on any intermediary devices.

Thereby making authentication and data protection an integral part of command execution and providing better security than is available in current systems such as smart cards.

The executive may be configured to perform operations as part of a predetermined and fixed sequence of actions upon receipt of a communication primitive to perform the operations specified in the current interaction context, the actions being specified separately as part of a process description associated with the accepted communication primitive, the process description including at least respective descriptions of the following actions (any of which may be empty):

a. authorization of use of the communication original code;

b. decrypting the operational data or any portion thereof;

c. executing a command with input data;

d. encrypting any operational data resulting from any performed operations;

e. the proof of completion of any performed action or the correctness of the derived data to be used in the secure computation is computed.

Security can be further enhanced if the data processing unit generates a random number of transactions that serve as a basis for cryptographic calculations when initiating data transfers.

In order to provide the possibility to enter a new interaction context when needed, a specified value can be assigned to a communication primitive, which will always be interpreted as a request to enter a new interaction context.

In a further preferred embodiment, the data exchange system according to the invention is characterized in that it comprises a further data processing unit formed by identical elements of the data processing unit, optionally containing in its memory an application programmer interface consisting of program code designed to allow the implementation of an additional computer program for the user to control the communication protocode sequence exchanged or to influence the data transmitted therein or to learn or further process the data received in the exchange.

In the preferred embodiment of the invention, the communication primitive used to enter the specified interaction context may comprise a value to be used in a secure computation in a subsequent communication, one of the processing elements generating a first value and possibly a second value to prove authenticity of or identify said one processing element, randomly or with similar unique properties.

To further benefit from the present invention, each communication protocode may be further constructed to include two or more numerical values that enhance the expressive power of the communication protocode for interpretation by the executing program.

As a first alternative, each communication primitive other than the first to send the reset signal may consist of two or more values, a first value being used to reference the procedural description of the action associated with that communication primitive, and a second value consisting of a fixed number of binary values, each of which is interpreted by the executive program as a reference to a single data element.

As a second alternative, each communication original other than the first one from which the reset signal is sent may be composed of two or more values, the first value being used to refer to a procedural description of the action associated with that communication original, and the second value being used to determine which of the data elements available for external reference in the context of an active interaction are to be used in performing the responsive action, i.e. if any data element contains a value that matches the second value or contains a value sufficient to indicate it, then that element is selected for use.

As a third alternative, each communication original code other than the first one transmitting the reset signal is composed of two or more numerical values, the first value being used to refer to the course description of the action associated with that communication original code, the second value being composed of several binary values, the executive program being assigned to their specific meaning for use in interpreting the data format in the communication original code or in performing the action of answering.

The portable processing unit described above may be implemented in a smart card or a PCMCIA card.

In a further elaboration of the invention the communication means utilize external communication means for establishing the data link, which external communication means are made available to the data processing unit by the data processing unit or by such similar electronic device receiving a PCMCIA or smart card implementing the data processing unit.

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

The communication device may utilize a smart card reader or a PCMCIA card slot.

Furthermore, the communication device may mainly or additionally utilize non-contact data transmission using electromagnetic field c.q. particles.

The context mechanism defined above and the techniques it enables to exploit lead to a wider range of smart card usage and a method of smart card application development, which have several advantages over the traditional approach.

First, it allows application specific program code in the smart card to be executed without having to thoroughly check the code for potential threats to the security of data stored by other applications. The multi-application card scheme does not require a program code checking authority since the access conditions stored on the card together with the data are reinforced by the card operating system without the possibility of external interference during the execution of the application code. This authority is the only way to allow private code execution facilities in traditional smart cards. By approving the code execution on the card, the checking authority assumes reliability on the security of the whole system; this makes the management of the multi-application smart card solution much more complex. The associated complexity and cost make application specific code in traditional card solutions almost infeasible. The requirements of the smart card application provider for this facility can be met using this new technology.

Second, as a direct result of the protected application specific program in the card, one specific application can be implemented that is dedicated to loading other applications in the card. In this way, once the applications are loaded in the card, they can be protected from tampering by the application that loaded them. This protection gives the parties participating in the multi-application card scheme the basis for their business agreements, especially the card issuing entity and the application provisioning entity. It is based on such things as the amount of memory required on each card, the number of cards to equip and the duration of the application on the card, rather than on such abstract concepts as "credit" and "good custody", that the application provider contract is easier to formulate than in a conventionally implemented smart card. However, the card issuer and the application provider do not need to share a secret key, and this sharing is protected with contractual obligations and mutually agreed key shipping facilities.

Third, the application software implemented according to the new technology has several advantages over prior art smart card operating systems:

only a minimum of data exchanges between terminal and card are required to establish the cooperation between card and terminal, e.g. they support the same application. The data values to be exchanged may be structured as proposed in the international standard ISO7816-5 draft;

the minimum number of data exchanges theoretically deduced can be practically used in order to complete a transaction between the card and the terminal, since it is done as a dedicated calculation, without using a lengthy standard command sequence;

it allows controlled access to data without the need for complex access paths governed by directories and file hierarchies shared by all applications as standardized currently in use and proposed;

if the terminal cooperates with the smart card application, development is allowed, which development process can be supported with computer software tools such as compilers and emulators. Thus, the design and implementation of the card and terminal software can be increased to more than the currently required troublesome and error-prone assembly code.

Allowing device standardization, both card and terminal, using an abstraction hierarchy to describe device capabilities, giving flexibility towards future developments, such as new features offered by the card or terminal manufacturer. The standardized terminal capabilities may contain APIs (application program interfaces). Unlike the current standardization in smart cards, the current standardization work focuses on specifying the fixed data content of the message in order to provide identification data that is interpreted in a standard-defined manner, which leaves little room for new developments.

Finally, by using the new technology, the implementer of the smart card operating system is given great freedom to design the operating system core of the card and the optimal implementation of the terminal operating system. Smart card hardware designers are given several options to optimize the use of silicon chips with hardware support for the basic operations contained in the system core. The hardware cost reduction obtained starting from the specialized design defined above can be greater than that obtained with improvements on general purpose single-chip computers.

The invention is described in detail below with reference to the accompanying drawings, which illustrate examples of implementations of the basic principles of the invention.

Drawings

FIG. 1 illustrates a prior art application design based on a hierarchically organized collection of data elements on a smart card;

FIG. 2 is a diagram illustrating the communication flow between a portable processing unit and a similar processing unit in a format currently accepted as standard;

FIG. 3 illustrates the basic construction of the present invention using an interactive context in a portable processing unit such as a smart card or PCMCIA card, and a more stable processing unit such as a card terminal or portable personal computer;

FIG. 4 represents an example of the actual organization of execution contexts, emphasizing the different relationships between process descriptions contained in the interaction context and the data elements and library functions used in executing the processes;

fig. 5 shows an example of a flow diagram of program execution control and security context switching contained in a process description invoked to execute a communication primitive.

Detailed Description

The data and file structure in a prior art system is depicted in fig. 1. Basically there is a main file 1 connected to several basic files 3 and one or more dedicated files 2. Each private file may be linked to one or more other private files 2 and one or more base files 3. The prior art uses a tree-like hierarchy of directories and files. The number of slave stages in the prior art architecture is in principle not limited. The terminology used in fig. 1 is taken from international ISO standard 7816-4. According to the portable data processing unit 5 as shown in fig. 2 and similar dataThe standard format of the communication flow between the processing units 4, the communication comprising a set of paired blocks. The communication is initiated by a reset signal m phi from the data processing unit 4. This reset signal may be outside the communication bandwidth, e.g. generated by the power-up logic in the data processing unit 5 but conceptually also part of the in-order exchange of messages. Answer To Reset (ATR) m for portable data processing unit 5₁The response may be followed by the content. All following blocks m₂、m₃、…m_(n-1)Mn comprises blocks preceded by respective values followed by content and constitute different communication originals.

Fig. 3 shows the internal structure of two data processing units according to the invention, which communicate with each other by sending and receiving data. The data processing unit 4 on the left may be a terminal and the data processing unit on the right may be a portable data processing unit, for example a smart card. However, the invention is also applicable to two or more portable data processing units capable of communicating with each other using suitable communication means or a suitable connection topology.

Each data processing unit 4, 5 comprises data communication means 7, 14 by which structural blocks of data can be exchanged. Each data processing unit comprises processing means 8, 15 and storage means 9, 16. The storage means 9, 16 may be any configuration of Read Only Memory (ROM), Random Access Memory (RAM) and programmable read only memory such as Electrically Erasable Programmable Read Only Memory (EEPROM).

The storage means 9, 16 comprise an executive program 12, 17, here denoted "MAXOS". If the portable data-processing unit 5 is suitable for two or more applications, the storage means 9, 16 comprise an application description 13(1) … 13(n), 18(1) … 18 (n). The application description is as many as the applications related to the data processing unit. Each application description is denoted by "CSA". Fig. 3 shows the second application descriptions 13(2), 18(2) on an enlarged scale so as to show the contents of the respective application descriptions. Each application description 13(i), 18(i) comprises at least one "interaction context" 11(1) … 11(m), 19(1), … 19 (m). Each interaction context is denoted by "CTA". The first of these interaction contexts 11(1), 19(1) are shown with a magnified scale to show their content. Each interaction context includes:

-a set of commands specifying the communication primitive identified by the interaction context and referring to the appropriate procedure specified in the set of procedures;

-a set of data;

-a set of data references to data located in other interaction contexts (if any);

a set of processes executable by the executive 12, 17;

-a set of access conditions to the data elements;

-a set of external references to data elements to be used by commands issued by other data processing units;

-optional developer-specific other tables.

Finally, the storage means 9, 16 comprise storage units 21, 20 containing references to "current CTA", i.e. the interaction context in the current implementation.

The intention of several interaction contexts in one application description is to provide a functional separation in the possible interactions between the data processing units 4, 5. This is particularly suitable when the functional separation is also a separation of safety conditions. An example of this may be a first interaction between the smart card and the terminal for opening a door, and a second interaction when programming a door that is allowed to open. The second interaction requires better security than the first interaction and gives it its own interaction context. In order to access the interaction context, the first step is to ensure the security of operations that can be performed within the interaction context.

FIG. 4 illustrates a practical scheme for implementing the context mechanism displayed as a memory organizational model that exposes relationships between data elements, access conditions, and processes. The structure of fig. 4 applies whenever there are two or more applications of the portable data processing unit 5. If there is only one application, the structure can be greatly simplified, as will be explained later. The reference numerals of the data processing unit 5 are depicted in fig. 4. However, the structure of fig. 4 is equally applicable to the storage means 9 of the data processing unit 4. The data element descriptions and process descriptions are optimally organized in FIG. 4 to reflect the sharing of program code and data between different interaction Contexts (CTAs) that make up an application (CSA).

Storage 16 includes data element H (1) … H (7), executable code element G (1) … G (5) as part of the operating system, and application descriptions 18(1), (18), (2) (CSA1, CSA 2). In fig. 4, data and code inside the operating system are omitted. The number of data elements, executable code elements and application descriptions provided in FIG. 4 are given as examples only: these numbers may vary according to actual needs.

Each application description 18(1), 18(2) appears physically in the storage device. They provide a first layer of abstraction to reflect memory usage. Each application description 18(1), 18(2) comprises:

a library of procedures consisting of executable code F (1) … F (4) which may reference code elements provided by the operating system for this purpose, as indicated by the arrow P (1) … P (5);

-a table of data elements E (1) … E (7) for use by the process within the interaction context 19(1) … 19(2) within the current application description 18. This data table contains data access conditions and pointers q (1) … q (7) to the storage areas where the data elements are stored;

-an interaction context table comprising several interaction context descriptions 19(1), 19 (2).

The number of elements in the process library, data element table and interaction context table within the application description 18(1) shown in fig. 4 is for representation purposes only. Of course, the number of elements may vary depending on the desired application.

The contents of the interaction contexts 19(1), 19(2) and the application descriptions 18(1) in the processing units 4, 5 participating in the data exchange are complementary in their data structures, i.e. the response from one unit is interpreted as a command by the other unit. By means of this complementary property, the most compact possible encoded content of the data structure can be generated from a single text description. Data exchange systems typically include many configurations of processing units with different purposes that communicate for the exchange of data during the course of operation of the system to accomplish this. Each processing unit may only contain portions of the data structures in its storage device that are relevant for its intended purpose in the system. The system as a whole is described by a collection of all the different content of the interaction context. Some interaction contexts or parts of their content can also be loaded at any time as needed. Such loading may be done securely, e.g. protected by the management application mentioned above.

The interaction contexts 19(1), 19(2) physically appear in the storage means storing the application descriptions 18 (1). Logically, the interaction context provides a second layer of memory usage control. This second layer, in combination with the combined control provided by the application description layer, efficiently implements an execution context mechanism for a portable data processing unit, such as a smart card. Each interaction context 19(1), 19(2) comprises:

-table of process descriptions C (1) … C (5). These process descriptions may refer to process descriptions in a process library within application description 18, as shown by example arrow S (1). Further, these process descriptions may reference executable code element G (1) … G (5) provided by the operating system, as shown by example arrow t (1). As another alternative, these process descriptions may contain explicit references to any data elements used by the process during execution and appearing in the data table of the associated application description 18, as indicated by arrow r (1) … r (6);

-a data table containing private data elements B (1) … B (5) that can be used by processes in the relevant interaction context. The data elements are represented as references to a data table with associated application descriptions 18 regarding access conditions to be followed when accessing the actual data, as indicated by the arrow u (1) … u (5);

-a table of external interfaces containing the communication protocodes a (1) … a (4) accepted as commands by the associated interaction contexts 19(1), 19 (2). Each command within the communication protocode references several process descriptions C (1) … C (5) of the process table within the associated interaction context, as shown by arrow V (1) … V (4). The command, when issued by the communication device 4, may reference an element in the data table of the application description with one or more addresses following the command. Each command may be accompanied by a data element as input to the command processing. The number of addresses given here is merely exemplary and is determined according to the actual needs of each command.

Protection of data elements is provided by proposing access conditions. Any external command within the communication primitive a (1) … a (4) can only address the data elements referenced in the data table of the associated interaction context 19. Access is only allowed if the access condition is satisfied. These access conditions specify the type of access the command is allowed to make; such access conditions may be no access, read-only access, read and write access, and secret key usage. Other access conditions can also apply. For example, a command of the communication original code a (1) can perform read-only access to the data element B (2) by referring to the arrow W (2), and a command of the communication original code a (2) can perform read and write access to the same data element B (2) by referring to the arrow W (3).

The process description C (1) … C (5) may reference data elements in the data table of the associated application description 18, but not others. Once again, access is only made when the access condition is satisfied. These access conditions also specify the type of access allowed: for example, no access, read-only access, read and write access, and secret key usage are permitted. For the same application description data table element E (1) … E (7), the access conditions described by different processes in the same interaction context 19 may be different, e.g. reference arrow r (1) may represent read-only access conditions and reference arrow r (2) may represent read and write access conditions.

The access conditions are checked at the relevant level, i.e. the application description level or the interaction context level, and only once. The element B (1) … B (5) of the data table in the interaction context 19(1), 19(2) directly references the pointer of the data element in the data table of the application description 18(1) by the arrow u (1) … u (5) because the access condition has been satisfied in the data table element E (1) … E (7) of the application description 18 (1). However, the process description C (1) … C (5) in the interaction context 19(1), 19(2) referring to the data table element in the application description 18(1) must first satisfy the access condition associated with the data table element E (1) … E (7) in the application description 18 (1). Any data element or process description element within the data table of the application description 18(1) and its associated interaction context 19(1), 19(2) cannot be referenced by any other application description in the storage means 16. The executable code that makes up the process descriptions can only address data indirectly through the restricted data reference groups associated with each process description C (1) … C (5). The executive temporarily extends the reference table with the data elements described in B (1) … B (5) by reference to the data elements that are estimated to be obtained as the actual specified address in the communication message accepted as the command associated with the process description. So that no other data can be accessed unless explicitly specified and subject to the specified conditions of use. In other words, the preferred memory reference model of FIG. 4 provides a dedicated context for operation within a single application of data processing unit 5 with respect to application descriptions and interaction contexts associated therewith. The data element H (1) … H (7) is stored in the storage means 16 common to all applications but contains data for exclusive use in the context of the application description 18(1), this exclusive use being guaranteed by the executive which only allows the presence of a single pointer to each storage location, such as q (1) from E (1) to H (2). Only code element G (1) … G (5) may be referenced by any application description 18(1) … stored within storage 16. The above-mentioned reference to the common code G (1) … (5) by application descriptions other than the application description 18(1) is not explicitly indicated in fig. 4. However, any person skilled in the art can easily extend the structure of fig. 4 to two or more of the application descriptions 18(1), 18(2), ….

Having described how data elements are protected using different kinds of access conditions, memory management provisions are described below. For memory management, it is desirable for the operating system to manage data that is changeable (data elements) separately from data that is not changeable (operating system code). The memory reference model shown in FIG. 4 provides separation of code and data elements within the storage 16, which are referenced by pointers q (1) … q (7), p (1) … p (5), respectively, from data tables and process libraries within the associated application description 18. The data table elements within each interaction context 19(1), 19(2) contain only references to these pointers and do not contain direct references to code G (1) … G (5) and data element H (1) … H (7) within storage 16. The data table of the associated application description 18 provides the level of indirection required by the operating system to perform memory management.

Code duplication is avoided by providing a common code base on both levels: the command body like process description C (3) references code element F (2) in the process library in application description 18(1) in order to share common code between different interaction contexts. However, the body of the process description C (3) also directly references the code G (3) stored in the storage means 16 and provided by the operating system. All code elements G (1) … G (5) provided by the operating system are implemented for efficient execution.

The code elements F (1), F (2) may be referenced with a memory address or with additional levels of indirection with an index in a suitably structured table. The hierarchy of references provided herein is well suited for such indexed implementations.

Basically, the memory structure according to fig. 4 is also applicable to the case where only one application of the data processing unit 5 is provided. In this case, the unique application description 18(1) may even coincide with an interaction context 19(1), which then contains the following relevant groups of definitions:

a. a set of elementary communication originals a (1) … received each time the data processing unit 5 communicates with a similar unit 4, said originals containing at least one original used to enter said at least one interaction context;

b. a set of process descriptions C (1) … defining actions to be performed in response to each received communication primitive A (1) …, including at least a first process description to be performed when an interaction context is activated and a last process description to be performed before the context is deactivated;

c. a permanently stored or computed set of potentially empty data elements H (1) … that are available for use in executing the procedure defined in procedure description C (1) …;

d. a set of potentially empty references to data elements associated with the process description C (1) …, which data elements are accessible by potentially other interaction contexts and are available for use in executing the process defined in the process description C (1) …;

e. a data table, which may be empty, containing data reference tables for data elements that are available as part of the communication protocode for explicit reference for use by the process description associated with the communication protocode;

f. a set of access conditions associated with data elements referenced in conjunction with the process description;

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

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

a. a data table containing references E (1) … to data elements, which are accessible by two or more interaction contexts 19(1) … and are extensible with additional data elements;

b. another set of access conditions associated with said reference E (1) … or said additional data element and defining a usage restriction.

The set of process descriptions in each of the two or more interaction contexts also includes an additional last process description for execution prior to deactivation of the context.

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

After the system is started, the software starts with the reset code processed in step 30. In step 31, the core operating security level of the data processing unit is entered. The access conditions describing this level are stored in a non-modifiable portion of memory, such as ROM or hardware logic. In step 32, the non-volatile memory is checked for compatibility and any incomplete modifications that may be left by a sudden power outage, such as by pulling out a smart card, are undone. The non-volatile memory compatibility check only includes checking the state information stored in the memory and calculating a checksum. The contents of the memory (if fully accessed) are used only to compute the checksum. Thus, the compatibility check is a safe operation. The exact nature of the compatibility check facility depends on the details of the hardware within the data processing unit and the routines of the non-volatile memory modifications, which are largely independent of the prescribed security architecture. After the overall memory compatibility check, the pre-computed level of the security context stored in memory is verified. Finally, the random access memory of the data processing unit is started.

In step 33, the security level of the data processing unit is entered if the execution environment is declared secure. At this level, any access to memory associated with core operations is blocked. Access to application data and descriptions from this level is provided exclusively by routines in the core that maintain state information for ongoing memory operations.

On the first entry after reset, the data element descriptor is applied in step 34 to check the stored data for compatibility with the descriptor, and if in a state inconsistent with the attribute, the memory is changed. An Answer To Reset (ATR) message is composed from the application identifier stored in the application descriptor and ends with a calculated transaction number that cannot be predicted by the further receiving data processing unit 4. A terminal command is generated inside the data processing unit to activate the default interaction context. Immediately after the ATR message has been sent to the further data processing unit 4, this internal context activation command is executed to provide an interaction context for the subsequent command. The ATR message clearly indicates that the data processing unit is ready to accept further commands. The default interaction context may be designed as part of the "smart card holder application", which is provided as a standard application in all multi-application smart cards. In this particular application context, the user (i.e. the smart card holder) can observe his personal data or open any other application on the card.

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

After the application has been fully activated, it is ready to receive commands from other data processing units. Further processing depends on the received command: the command to activate an application is handled differently than the command to be executed. Thus, after determining that the communication original was received in step 36 and that it was acceptable in step 37, it is checked in step 38 whether a new application needs to be activated. If not, step 39 is followed in which the command is checked to determine whether input data is allowed and acceptable. These checks are only performed on commands specified in the application descriptor. Decryption of the input data may also be performed in step 39.

If the check is successful, the "data access protection stage" is entered at step 40. At this level (highest security level), the routine of applying the provider code is executed at step 41. These routines are stored in the application descriptor and act as specific reactions for the application to the specific command issued by the other data processing unit 4. This level of security limits memory accesses to a subset specifically defined for the command being executed.

After executing the command with the input data committed in step 41, the data access protection stage is exited in step 42.

In step 43 an (encrypted) proof of the completion of the output data and the command is generated. This function is only a command execution that specifies doing so in the process description, and the combined action may be null for any definition. The program waits for a new communication original at step 36 after step 43.

If a dedicated command routine is not defined and the command can be executed with a process that contains only operating system functions, the data access protection level is not entered (step 40), and the command will be executed directly on the interaction context security level because the operating system routine is designed not to break any data protection.

If it is determined in step 38 that there are no new applications to activate, the program proceeds to step 44 where a context deactivation process is performed. In step 45, the current application-specific security level is left, and in step 46, the data accompanying the command is checked at the security level of the executing program "MAXOS".

If the appropriate authentication specified for the requested application allows the command, a new application specific CTA security level is entered at step 47. This level will restrict access to data that the newly opened application has.

In step 48, the data processing unit generates data in response to the context activation command by executing the initialization instructions defined in the process table. If such an application provider encoded routine is present, the data access protection level is entered at step 49. The context activation process is performed in step 50. Leaving the data access protection stage and passing the acknowledgement to another data processing unit 4 in step 51, and the data processing unit 4 is ready to receive a new command after step 43, as described above.

Having described fig. 1 to 5, some general explanations of the data exchange system according to the invention will be made below.

The code in the process libraries within each application description 18(1), 18(2) may be enhanced by incorporating their operating parameter specification into the use of which parameters are classified into categories relating to attributes of data elements that can be passed as actual values in calculations that are only made if the data attributes match the parameter classes. This provides a way to verify the access conditions of both the data element and the function. Comparing the properly encoded data attribute bitmap to the parameter classes can provide an efficient implementation for this additional technique.

The executing program 12, 17 may contain a reference to an interaction context that is used to initialize the current interaction context in the memory unit 20 that stores the reference to the interaction context currently being implemented. With this measure it is possible to perform the last action after a restoration to a normal operating state of internal incompatibility is detected or whenever the execution program 12, 17 is started but the communication primitive received from the other data processing unit 5 does not specify an explicit interaction context. This default interaction context may also be one that is included in the above-described card-holder application.

Furthermore, the storage means 9, 16 may comprise an interaction context 11, 19 dedicated to containing a Personal Identification Number (PIN), and the executive program 12, 17 is configured to authenticate a personal identification number provided by a user of the data exchange system. Several personal identification numbers and passwords may be used. A password may be used to protect the device for use in transactions where privacy sensitivity may be compromised. The second password may be used to secure the transaction in the event that data representing the amount of money the password holder may pay is transferred. The third password may be used to protect transactions in which the performed operation is deemed to be a significant security concern for the application, such as the requesting protection mode specified in each interaction context 18 that may require it. Other passwords may be provided. This PIN management interaction context may also be one such context contained in the above-described card-holder application.

Each application description 13, 18 may comprise a table of values, which is structured to provide identifiers for all interaction contexts 11, 19, and each application description 13, 18 may comprise a combination of any of the following values: a first value representing the type of application, a second value representing the unique identification of the entity offering the application, a third value representing the nature of the application description 13, 18 and further numbers each uniquely referring to an interaction context 11, 19. The first two numbers may be assigned according to rules strictly established in commerce, while the remaining numbers may be selected by the application provisioning entity as deemed appropriate. In particular, values may be assigned to distinguish different versions of an implementation or to identify the generation of a keyset employed by an application in its cryptographic calculations. Furthermore, the device may include in the reply message to the reset a table of identification numbers for each application context 11, 19 contained in its storage means, consisting of the unique identification value stored with the interaction context. The first element in the table of interaction context identification numbers may be an identification of a default context.

The data communication means 7, 14 are preferably arranged to constitute data exchanges in data blocks. The data blocks comprise at least two parts, the first part being data considered as operational data which is used to influence the nature of the operation performed by the command indicated by the communication primitive or data derived from the operation performed. The second part is considered security data which is used to determine the appropriateness of performing an operation or the acceptability of the data within the operational part for use in the operation or to prove the completion of the operation or the correctness of the data revealed.

When the data is structured in this manner, the executive 17 can be configured to perform the operations specified in the current interaction context 20, 21 upon receipt of the communication protocode, each as part of a predetermined and fixed sequence of actions, each operation being specified separately as part of the process description rules associated with the accepted communication protocode. The first action may specify a function that permits use of the communication primitive at this point in the communication sequence. The second action may be specified as a function of decrypting the operational data or any portion thereof, while the third action may be specified as an appropriate operational procedure. The fourth part may be specified as encrypting any operational data derived from the performed operations, while the fifth action may be specified as a function of calculating a completion of the performed action or a proof of correctness of the derived data, or a security calculation for use in the receiving data processing unit. These actions are reflected in the flow chart of fig. 5.

In addition, the data processing unit 5 contains in its response to the reset message a number selected such that its value cannot be predicted by the receiving data processing unit 4, which can be used as a basis for cryptographic calculations. This number may be designated as the "card transaction number".

A communication primitive may be provided that is assigned a specified value and interpreted as a request to enter a new interaction context 11, 19. This communication nonce may be designated as an "activate command". The data accompanying this activate command is sufficient to specify the context that may be activated by referencing the identification number passed as part of the reply to the reset message. The action performed in response to this activation command is described firstly by the description of the process designated as deactivated, contained in the context of accepting the original code, and secondly by the description of the process designated as activated, contained in the context designated as to be entered.

The communication primitive used to enter the specified interaction context 11, 19 preferably includes a value to be used in secure computations in subsequent communications. The first value may be randomly generated by one of the processing units and the second value may be used to identify one of the processing units. The values may be calculated differently as required by the encryption protocol used, and this difference may be specified as part of the process description C1. This identification may be the result of a calculation, which is such that the resulting value is sufficient to identify the state of the device and its memory required for a possible calculation or other action to be performed in a subsequent data exchange in the interaction context 11, 19 to be activated. The second value may be designated as "terminal identity".

In addition, the activation command gives as part of the result data a value to adequately identify the particular responding data processing unit required for possible calculations or other actions to be performed in the subsequent data exchange in the context being activated, which number may be designated as "smart card identification".

Furthermore, the identification number for the smart card can be calculated with a cryptographic function from data stored in the data processing unit 5 or from data received as part of an activation command in such a way that the number changes in an unpredictable way when calculated in response to an activation command received from an initiator device with a different terminal identification number; the smart card identification thus calculated may be designated as "smart card pseudonym". Further, before performing the action described in the process description of the activation process of the context to be entered, the execution program may perform the cryptographic calculation specified as the process description, that is, specify the context to be executed at the time of activation to determine whether the context can be activated. These calculations may include the use of smart card transaction identifications, terminal transaction identifications and terminal identifications and other values stored in the storage device.

As an alternative to these encryption protocols supported with specific data in the activate command, a command with a bit field description of the referenced data element may be used. Each communication primitive is then composed of two or more values, the first value being used to reference the procedural description of the action associated with that communication primitive, and the second value being composed of a fixed number of binary values, each binary value being interpreted by the executive program 12, 17 as a reference to a single data element. This data element is specified in an external data element reference table in the relevant interaction context 11, 19, each data element in the table being specified by the binary value of one binary number at the corresponding position in the table of binary values. This second value may be designated as an "operand address". Each data element thus specified is used in the response action by the operation execution program 12, 17 in the manner described in the course description of the action.

As an alternative to an encryption protocol and a command with a bit field description of a referenced data element, a command format with a data match description of the data element may be applied. In this case, each communication primitive is composed of two or more numerical values, a first value being used to reference the course description of the action associated with that communication primitive, and a second value being used to determine which of the externally referenced data elements available in the activated interaction context 12, 19 are to be used when performing the responsive action, i.e. to select any data element if it contains a value matching said second value. This second value may be designated as "operand tag specifier". Additionally, a process description may be included in the interaction context 11, 19 indicating the manner in which the operation marker specifier given as part of the command is compared to data contained in any data element available for external reference in that context, which process description is executed to select the intended data element before the execution of the process description specifies the appropriate command action.

In another alternative, a command format with a bit field description of the command interpretation may be used. Each communication primitive now consists of two or more values, a first value to reference the course description of the action associated with that communication primitive, and a second value consisting of a number of binary values, the executive programs 12, 17 giving them specific meaning for use in interpreting the data format in the communication primitive and performing the response action. The second value may be designated herein as a "command modifier". All units equipped with this additional technique are able to recognize the meaning assigned to these values.

If the latter alternative is applied, the command modifier may comprise a binary value that determines whether the third portion of the command is to be used as an operand address or an operand tag specifier. However, as an alternative, the command modifier may comprise a binary value that determines whether an operation performed in response to the command will use data as one data element or data consisting of a concatenation of data elements, each data element being processed in conjunction with a respective data element specified as part of the command with an operand address or operand tag specifier. Alternatively, the command modifier may comprise a binary value that determines whether the data provided with the command is encoded using the mark-length-value method to distinguish between successive concatenated data elements.

Alternatively, the command modifier may contain a binary value that determines whether performing the action implied by the command will actually result in an actual change of the data stored in the data processing unit 5 (smart card), or in data calculated by the data processing unit 5, or that the command result is data reflecting the status of the unit's acceptability for the command, the data accompanying it, the length of the data that may be derived from the calculation, or other miscellaneous properties.

In short, the new technology presented above, implemented in smart cards, is the concept of a stand-alone execution environment. In this approach, the processing device and other resources in the computer are shared between different applications as if the application were the only user of the computer. Based on this new technology in smart card implementations, a mechanism is additionally provided to define a variety of access conditions for data shared by several related applications. The second technique, which is supported by the independent execution environment and is described above, is the possibility to define the functional meaning of commands in each environment to achieve a minimum number of commands in each interaction between two similar data processing units 4, 5 in the data exchange system. Finally, it is possible to use new techniques for assigning names that reference stored data elements separately in contexts. Thereby enabling a reference to a stored data element as part of a command received from one of the data processing units 4, 5 to be made valid: because of the very few data elements and the few distinct operations used in current smart card practice, only a few bits are needed in each environment to encode name and instruction spaces. In a practical smart card, the access conditions, their authentication methods and the encryption operations in a similar manner are very limited in number and they can be represented very efficiently in a two-layer hierarchy of the interaction context description 19(1) … encapsulated in the application description 18.

Claims (16)

1. Data exchange system comprising a plurality of data processing units (4, 5), of which portable processing units establish temporary communication links (6), whereas other units which cannot be moved may have a permanent communication link (6), said units comprising data communication means (7, 14), processing means (8, 15) and storage means (9, 16), the latter comprising an execution program (12, 17), characterised in that the communication means (14) is arranged to form the data exchange in a data block comprising at least two parts, a first part being data suitable for the operation and intended to influence the nature of the operation performed by the command indicated by the communication primitive or data derived from the performed operation, and a second part being suitable for security and intended to be used to determine the appropriateness of the performed operation or the acceptability of the data within the operating part for use in the operation or to prove the completion of the operation or the correctness of the derived data.

2. A data exchange system according to claim 1, characterized in that the executive (17) is arranged, upon receiving a communication primitive performing an operation specified in the current interaction context (19(l) …), to perform the operations as part of a predetermined and fixed series of actions, the actions being specified separately as part of a process description associated with the received communication primitive, the process description including at least a respective description of the actions, any of which may be empty:

a. authorization of use of the communication original code;

b. decryption of the operational data or any portion thereof;

c. executing a command with input data;

d. encryption of any operational data resulting from any performed operations;

e. completion of any performed action or calculation of proof of correctness of the resulting data to be used in the secure calculation.

3. A data exchange system according to any one of the preceding claims, characterized in that the data processing unit (5) generates a random transaction number when initiating data transfer, which is used as a basis for cryptographic calculations.

4. A data exchange system according to any one of the preceding claims, characterized in that a communication primitive is given a specified value which is permanently interpreted as a request to enter a new interaction context (19(l) …).

5. A data exchange system according to any one of the preceding claims, characterized in that it comprises a further data processing unit (4) having the same elements as the processing unit (4), optionally containing in its memory an application programmer interface (10) containing program code designed to allow an additional computer program to be implemented to enable a user to control the exchanged communication protocodes or to influence the data transmitted between them or to learn or further process the data received in the exchange.

6. A data exchange system according to claim 5, characterised in that the original code used to enter the specified interaction context (19(l) …) includes a value used in secure computation in subsequent communications, the first value being generated by one of the processing elements randomly or with similar unique properties, and the possible second value being used to prove the authenticity of or identify said one processing element.

7. A data switching system according to claim 5, characterized in that each communication original other than the first communication original transmitting the reset signal is composed of two or more numerical values, the first value being used to refer to a procedural description of the action associated with the communication original, the second value being composed of a fixed number of binary values, the executive program (12, 17) interpreting each binary value as a reference to a single data element.

8. A data switching system according to claim 5, characterized in that each communication primitive, in addition to the first communication primitive that sends the reset signal, consists of two or more values, the first value being used to refer to a procedural description of the action associated with that communication primitive, and the second value being used to determine which data elements referenced outside the interaction context (19(l) …) available for activation are to be used when performing the responsive action, i.e. any data element is selected if it contains a value that matches said second value or if it contains a value sufficient to indicate it.

9. A data switching system according to claim 5, characterized in that each communication original is composed of two or more numerical values in addition to a first communication original for transmitting a reset signal, the first value being used to refer to a process description of an action associated with the communication original, the second value being composed of a number of binary values, the executing program (12, 17) giving these binary values a specific meaning for use in interpreting the data format of the communication original and in performing a response action.

10. A data exchange system according to any one of the preceding claims, wherein the portable processing unit is implemented in a smart card.

11. A data exchange system according to any one of claims 1 to 9, wherein the portable processing unit is implemented in a PCMCIA card.

12. A data exchange system according to claim 10 or 11, characterized in that the communication means (14) establish the data link (6) by means of external communication means which can be made available to the data processing unit (5) by the data processing unit or the similar electronic device housing the PCMCIA or smart card implementing the data processing unit (5).

13. Data exchange system according to any one of claims 1 to 9, characterized in that the data processing unit (4) is implemented as a portable personal computer.

14. A data exchange system according to claim 12 or 13, characterized in that the communication means (7) utilize a smart card reader.

15. Data exchange system according to claim 12 or 13, characterized in that the communication means (7) utilize a PCMCIA card slot.

16. A data exchange system according to any one of claims 10 to 15, characterized in that the communication means (7) primarily or additionally utilizes contactless data transmission by means of particles of charged magnetic field c.q.