WO2007122266A2

WO2007122266A2 - Protected execution of a service provider's data processing application for a user by means of a trustworthy execution environment

Info

Publication number: WO2007122266A2
Application number: PCT/EP2007/054117
Authority: WO
Inventors: Peter LANDGENDÖRFER; Michael Maaser
Original assignee: Ihp Gmbh - Innovations For High Performance Microelectronics / Institut Für Innovative Mikroelektronik
Priority date: 2006-04-26
Filing date: 2007-04-26
Publication date: 2007-11-01
Also published as: DE102006020093A1; WO2007122266A3; EP2014048A2

Abstract

The invention relates to an execution container for a service provider's data processing application. Said execution container comprises at least one execution environment, a communication interface that is connected to the execution environment, and a security control unit which is connected to the communication interface and is configured so as to prevent the data processing application from communicating data with any communication terminal external to the execution environment if the data communication path circumvents the execution environment. An access control unit is also provided which is connected to the communication interface and is configured so as to prevent the execution environment from communicating data with any communication terminal which is external to the execution container and is not defined as authorized through a first security agreement.

Description

Protecting a data processing application of a service provider for a user by a trusted execution environment

The invention relates to an execution container for a data processing application of a service provider.

The protection of personal data against unauthorized disclosure and use by third parties is a major concern of users of remote data transmission networks such as the Internet. In the English expression this concern is formulated more scarce than "privacy protection".

Wireless access networks to remote telecommunications networks are becoming increasingly equipped for data processing applications in which selected information or advertisements are sent to a user terminal in accordance with their current location. Network operators or service providers who operate a corresponding location-sensitive data processing application in this way can track the behavior of a user without his consent.

It is known to give a user the opportunity to explain to what extent he wishes to provide his personal data (such as his current whereabouts or his terminal identifier, etc.) to a service provider. In the context of this patent ap- proach, such data are summarized under the general term user input data.

Other approaches to protecting this data may allow a user to establish rules specifying who may have access to information about the whereabouts of a user's terminal and under what circumstances that access is permitted. Alternatively, it has been proposed to intentionally disturb the position determination in order to reduce its accuracy and thus to keep the location of a user terminal secret. All these approaches lack a means to enforce the protection of personal data.

The documents US 2003/158960 A1 and US 2004/0181683 A1 disclose protective mechanisms for the protection of personal data. Disadvantage of the protection mechanisms described therein, however, is that the personal data is provided to the service provider of a data processing application. This further allows unwanted copying, saving and distribution of this data.

US Patent Application Publication No. 2004/0181683 A1 also discusses a "trusted agent" approach, in which an "international security, trust and privacy framework work" allows a user to provide the service provider of a data processing application with several profiles for which the service provider - Beiter then generated according to personalized user output data. The personal data of the user is protected by the fact that the service provider does not know which of the profiles is correct. It is also suggested to distribute the correct user input data to multiple profiles.

A disadvantage of this concept is that the generation of useful user output data by the service provider is made more difficult if the user's personal data belonging to different user profiles belong together are distributed. However, if all the relevant information is included in a profile, then the probability is high that the correct user input data can be determined, at least when the user makes more use of the service provider's data processing application. Furthermore, guessing the correct user input data is simplified by generally sending all the wrong profiles together with the correct profile from the user terminal together.

Even if, as proposed in US 2004/0816831 A1, a trustworthy third party creates the wrong and correct user profiles, the so increased protection of the user can be undermined by the fact that this trusted third party is being explored. In addition, this approach lacks the ability to prevent the copying and saving of data.

From the document Crane, Stephen: Privacy Preserving Trust Agents, HP Technical Reports, HPL-2004-197, available online at: http://www.hpl.hp.com/techreports/2004/HPL-2004-197.html, It is known that an agent created by the service provider protects the user terminal. In the scenarios described in this document, the agent is installed by a system administrator and monitors security settings on the terminal when used outside of a site assigned to the customer's employer. In another scenario, said agent is provided by an Internet Service Provider (ISP) and monitors, for example, children's internet use for filtering dangerous information.

In this context, the use of a "Privacy Preserving Trust Agent" is described, which negotiates the use of data with the ISP, but does not itself provide any data protection.

- Passing the data on to a trusted third party, which then passes the data on to the ISP. However, no actual protection of the data is recognizable. - A -

- Disclosure of the data to the ISP with a usage rule ("Usage Policy") It is unclear how the enforcement of this usage policy can be enforced

Usage policy can only be determined later. But then the data to be protected has already been abused.

The technical problem underlying the present invention is therefore to provide a device for executing a data processing application of a service provider for a user with an improved protection of user input data.

According to the invention, the technical problem is solved by an execution container for a data processing application of a service provider. The execution container contains:

at least one execution environment configured to instantiate and execute the data processing application that processes user input data to generate user output data in the form of executable program data, and to exchange the user input data and the user output data with the data processing application;

a communication interface connected to the execution environment and configured to receive user input data and forward it to the execution environment, and output user output data sent from the execution environment to outside the execution container;

a security control unit connected to the communication interface and configured to prevent such data communication of the data processing application from any communication execution endpoint external to the execution environment whose communication path bypasses the execution environment; and an access control unit connected to the communication interface and arranged to prevent such data communication of the execution environment with any relative to the execution container external communication endpoint, which is not defined as permissible by a first security agreement.

The device according to the invention has the advantage that the data processing application of the service provider can not be executed by the service provider itself, but by a trusted execution entity. This can be done on the equipment of the service provider, the service user or a third party. The device according to the invention is referred to in the context of the present application as an execution container.

In the execution container according to the invention, it is ensured that the service provider does not receive user input data. Although the data processing application exchanges user input data with the execution environment. However, in the embodiment container according to the invention, it is ensured that the user input data made available to the data processing application can not be sent uncontrollably to the outside, that is, for example, to the service provider of the data processing application. The access control unit prevents data from the execution environment from being sent to external communication endpoints that are not permitted by a first security agreement. Typically, the first security agreement is concluded between the provider of the data processing application and the user. The security agreement is in the form of a file for the execution container. The access control unit uses the first security agreement to monitor and, if necessary, prevent the data communication of the execution environment with external communication endpoints.

Furthermore, the safety control unit provided in the embodiment container ensures that only the execution environment, but not the data processing application itself, can communicate with communication endpoints that are relative to the execution environment are arranged externally. The security control unit actively prevents any data communication of the data processing application whose communication path bypasses the execution environment. This means that the security control unit in particular prevents direct, uncontrolled communication between data processing applications that are embedded in different execution environments within the execution container. In an embodiment described in more detail below also include so-called. Covert channel attacks on the security of the execution container.

In the embodiment container according to the invention, the execution environment provides the necessary infrastructure, such as access to the processor, etc.

In the present context, a security agreement is understood to be a regulation which is present in file form and defines which data communication may be sent to which communication endpoints. Furthermore, the security agreement may contain information about what data a data processing application (DVA) may receive from the user as well as what data the user may receive from the DVA. If in the present application in the context of the invention of "security" is spoken, the term in the sense of the aforementioned "privacy protection" as protection against unauthorized disclosure and recovery of personal data to understand. What personal data is defines a respective security agreement, so it varies from individual case to case.

As a data processing application executable program data in the context of the present application, for example in the form of at least one executable file or at least one script. Examples of data processing applications will be discussed later in the description of preferred embodiments.

Permitted data communication, in particular under permitted user input data, is to be understood as user input data which are defined in the security agreement on the basis of verifiable criteria. A permissible keitskriterium can be, for example, a threshold value associated with a position determination of a user terminal measurement accuracy. Another admissibility criterion may stipulate, for example, that address data, either in the form of the residence of a user or in the form of a network address of a user terminal of this user, are not made available to the execution container. In a corresponding manner, eligibility criteria for user output data as well as a permissible recipient of the user output data with respect to the respective data processing application can be defined.

The first security agreement between the service provider and the user accordingly regulates the data flow between the user and the execution container on the one hand and the execution container and the authorized recipient (s) of the user output data. In this case, the user output data to be sent can also be sent differentiated according to the recipients. For example, the transmission to the service provider may be limited to billing data, while other user output data may be transmitted to the user himself, for example, to provide him with the service provider's service associated with the data processing application.

The first security agreement is implemented in the execution container. This means that the execution container always has access to and adheres to the associated first security agreement during execution of the data processing application.

Embodiments of the embodiment of the invention container will be described below. In this case, different embodiments can be combined with each other, as far as this is not expressly excluded by the respective description.

In a preferred embodiment of the execution container, the latter has a memory for user input data that is external to the execution environment and that is accessible via the communication interface with the execution environment. is connected. In this embodiment, the security control unit is designed to prevent a direct access of the data processing application to the memory. Thus, memory accesses can not be performed by the application itself without involving the execution environment in such an operation. This can however ensure that the data processing application does not access the memory in an inadmissible way.

A further development of this exemplary embodiment provides for designing the execution environment in such a way that external user input data relative to the execution container can be read via the communication interface and a local copy of the external user input data can be stored in the memory. Access to external user input data is in this embodiment solely by the execution environment. The data processing application receives no access rights to external user input data in this exemplary embodiment.

In another embodiment, the execution container includes a negotiation unit and a negotiation interface. The negotiation unit is designed to negotiate the first security agreement between a service provider and a user via the negotiation interface in accordance with a predefined negotiation protocol. In one embodiment, the first security agreement includes the following information:

Literals, the z. B .: may be communicated to the outside for control purposes

Permitted communication endpoints

- User input data that may be forwarded from the execution container to the DVA.

In another embodiment, the execution container has a negotiation unit and a negotiation interface, and the negotiation The unit is designed to negotiate a second security agreement between the execution container and a service user via the negotiation interface in accordance with a predefined negotiation protocol, wherein it contains the following information:

an address of at least one data store external to the execution container to which read access of the execution container is permitted, or

User input data that is allowed read access by the execution container.

The second security agreement provides a tool that allows the execution container and the user to determine how the user input data defined in the first security agreement is made available to the execution container. In addition to sending the user input data from a user terminal to the execution container, in practice it often makes sense to allow the execution container access to user input data, for example, if this is frequently updated data.

Accordingly, user input data can either be sent by the user to the execution container and stored in this or be picked up by an access of the execution container user-stored user input data from the execution container itself. The transmission step may also occur in connection with the implementation of the data processing application in the execution container in certain data processing applications. In general, however, it will be performed by the execution container in connection with the execution of the data processing application.

It is noted that the security control unit and the access control unit of the execution container are integrated into a single unit in one embodiment. This integrated unit, like the safety The control unit and the access control unit itself, in the presence of a distributed execution container also be distributed over these multiple execution container.

In another embodiment, the security control unit is designed to also exercise its functions as a function of contents of the first or second security agreement or depending on contents of both security agreements.

Particularly preferred embodiments provide protocols for negotiating the security agreements. In one embodiment, therefore, a step of negotiating the first security agreement between the service provider and the user is provided according to a predefined privacy negotiation protocol. This step is performed before the step of receiving the first security agreement at the execution container. For example, the privacy negotiation protocol may define formats of offer and counter offer messages that may be exchanged between the user and the service provider. Furthermore, the privacy negotiation protocol may define security preferences formats to be filled by the user or service provider with their respective security preferences. The respective security preferences are then exchanged between the user and the service provider with the predefined security preferences format by sending corresponding messages according to the negotiation protocol. This allows the sender and recipient to automatically negotiate the security agreement.

In a preferred embodiment, users and service providers define at least one set of respective security preferences as well as non-negotiable minimum preferences and negotiable additional preferences. By defining a negotiation strategy prior to the negotiation according to a negotiation strategy format predefined in the privacy negotiation protocol, it is even possible to carry out the negotiation fully automatically. For example, in a negotiation strategy, each party may define that the negotiation will be terminated if a non-negotiable minimum from the other side is not accepted. Furthermore, a negotiation strategy may provide that instead of aborting a negotiable additional preference, a counter offer or a new offer of its own with a changed value of the negotiable additional preference is created.

If there is an agreement between the negotiating parties, this is preferably acknowledged by signing the current offer or counter offer. The execution container may then insert a further verification step prior to implementing the security agreement, including checking the signatures of a received security agreement. This ensures that only genuine security agreements between the service provider and the user are implemented, further increasing the trustworthiness of the execution container. It goes without saying that signatures of the first security agreement can also be attached to the negotiation protocol without a negotiation between the user and the service provider in order to ensure the authenticity of the security agreement.

The execution environment is designed so that data that is no longer needed can not be retrieved later from a third party. This may, in a particularly preferred embodiment, e.g. be achieved by causing a deletion in the memory of stored user input data and user output data of the data processing application after completion of the execution of the data processing application,

In another embodiment, the execution environment is designed such that access to the third-party program data is not possible. This may e.g. be achieved by causing the instantiation of the execution of the data processing application to eliminate the instantiated executable program data of the data processing application.

In a further embodiment, the security control unit or the access control unit is adapted to check the presence of a criterion for termination of the validity of the first security agreement, and at Presence of such a criterion to cause a deletion in the memory of stored user input data and user output data of the data processing application.

In this way, it can be ensured for the benefit of both the service provider and the user that the data processing application is executed only during the period of validity of the first security agreement. For example, a criterion for terminating the validity of the first security agreement may be determined by a timeout in the first security agreement itself. The first security agreement may also be used as a termination criterion for its validity to expire if a violation of the eligibility criteria defined in the security agreement is established.

Thus, if a criterion for terminating the first security agreement is stored, the user input data and user output data stored in the execution container are preferably deleted. This ensures that this data is not made available to anyone. For the purpose of protecting the service provider, provision can advantageously be made, alternatively or additionally, for the data processing application implemented in the execution container to be deleted if a criterion for terminating the validity of the first security agreement exists.

It may then be provided to generate and send a message to the user and the service provider reporting either on the existence of the termination of the validity of the first security agreement or on the deletion of the user input data, user output data and / or user data processing application stored in the execution container.

The execution container of the present invention forms a service model. The execution container can be operated, for example, by the service user, by the service provider, but also by a third party. Within an execution container, a plurality of execution environments may be provided for data processing applications. In each of these embodiments But only one DVA can be instantiated and active. Thus, it can be ensured that there is security for the user as well as for the provider of the data processing application against misuse of the exchanged data or data processing capacities. A preferred execution container accordingly contains a plurality of execution environments. To maintain security, the execution environments are configured to prevent any communication between different computing applications in relatively external execution environments within the execution container. It is thus ensured that the data processing applications instantiated in an execution container can not influence one another or can mutually access one another.

Data communication with external data processing applications relative to the execution container in external execution environments may be facilitated in a preferred embodiment without compromising security that the execution environment of the execution container is configured to respond to a command received from the data processing application via the communication interface To send a literal selected from a set of given literals to a communication endpoint external to the execution container. In this embodiment, for a data processing application, a set of predefined literals that can be exchanged with external execution environments is provided. Of course, this exchange must be permitted under the first security agreement. The use of predefined literals, ie, predefined commands and messages allowed in the communication between the data processing application and an external execution environment, enables dedicated communication which, at the same time, can easily be checked for eligibility based on its predefined patterns at runtime. It should be noted that in this embodiment, the data processing application does not send a literal itself, but the broadcast is made by the execution environment. This ensures that the data processing application does not automatically contact external communication endpoints. However, it is conceivable that the predefined literals will be used by a suitably manipulated data processing application to "throw out" inadmissible information from the execution container, thus proposing the total number of literals, the number of times that literals are made, or the duration of an execution In a preferred embodiment, therefore, the execution environment is configured to send at most a maximum number T of data bits via predefined literals. The maximum number T is defined by

L

where n is the number of literals transferred, L is the total number of predefined literals, f is the frequency of transmission of literals, and t is the length of a session in which literals are sent.

Another possible attack on the security of the execution container is to create transmission channels that are not provided by the execution container for information transmission. Such channels may be formed, for example, by the data processing application selectively generating varying processor utilization, with certain processor utilization states being able to represent particular bit values or symbol values having a higher number of bits. for a duration of one second as bit value "1", while a lower average CPU load could be agreed as bit value "0" for one second during the duration of one second CPU utilization can be read by known technical means In a preferred embodiment, therefore, the execution environment is configured to charge a processor usable by the execution container for a non-predetermined time pattern that is independent of an actual load of the data processing This will prevent the data processing application from gaining control of processor utilization alone. Similar measures are for the utilization of a memory conceivable. The time pattern must be random, ie controlled by a random number generator.

In order to be able to execute on mobile terminals with limited resources, such as computing power and battery capacity, data processing applications of a service provider with the security created by the present invention, a distributed execution container is proposed, which includes a first and a second execution container according to the invention described above , Of course, the distributed execution container may also contain more than two individual execution containers. For the sake of simplicity, the following description will focus on the case where it consists of two execution containers, without restricting the generality of the applicability of the concept of the distributed execution container. The two execution containers are connected via a data transmission channel for the exchange of data. The execution container is designed to identify itself to the respective other execution container with the aid of a suitable authentication mechanism. Furthermore, the communication interfaces of the execution container are designed to exchange data in encrypted form via the data transmission channel.

There are basically two options for providing an execution environment. On the one hand, an interpreted language could be used and the necessary interpretation means could be provided in the execution container. A data processing application in this case would be provided in the form of a program in the intended language by a corresponding service provider. By providing interpretation means for different programming languages, the flexibility of the execution container could be increased using this concept. However, this results in the execution container having to provide unnecessarily large amounts of data and is not a viable solution for limited-capacity hardware such as PDAs. Therefore, a second option is preferred, namely the use of a platform-independent byte code in the data processing applications. Accordingly, the execution environment may include an application environment such as a Java runtime environment or a .NET runtime environment. Both alternative and known application environments provide the performance and effectiveness needed to implement complex services and data processing applications. The DVAs represent compiled code and provide a suitable execution speed. It should be noted, however, that the application environment is to be adapted according to the invention. For this purpose, appropriate additions to the known application environments are required.

Hereinafter, further embodiments of the method and the device according to the invention will be described with reference to the figures.

Fig. 1 shows a simplified structure of an embodiment container according to an embodiment of the invention;

Fig. 2 shows the structure of a distributed execution container according to another embodiment of the invention;

Fig. 3 shows the flow of negotiation over a security agreement for use in an embodiment of the invention.

Fig. 1 shows a simplified structure of an execution container 100 according to an embodiment of the invention. The container contains a number of execution environments as fixed components. For the present example, it is assumed that execution container 100 includes two execution environments 102 and 104. Other embodiments may include only one or more than two execution environments. The execution environments 102 and 104 provide an infrastructure that includes all means for instantiating and executing a data processing application in the form of executable program files, scripts, or the like. The execution environment is realized in the present embodiment by an application environment. Examples of known application environments are the Java runtime environment or the .NET Common Language Runtime (CLR). The application environments 102 and 104 are basically the same. Compared to known runtime environments, they must be for a Implementation of the present invention, as will become apparent from the following description in detail.

Each execution environment of the execution container 100 is designed to instantiate and execute a data processing application 106 or 108 in the form of executable program data. A data processing application is provided to the execution container by a service provider in the form of a platform independent bytecode adapted to the application environment in which the execution container operates. The data processing application can be transmitted, for example, in the form of Java byte code or in the form of a program file present in .NET Intermediate Language (CIL). This is compiled code that is capable of ensuring the execution speed required for most data processing applications.

In the following description, it is assumed without limitation that the execution environments 102 and 104, as well as 100, are embodied in the Java runtime environment.

The data processing applications 106 and 108 may be different types of data processing applications. A rough distinction of data processing applications can be made in data delivery services, data control services and goods delivery services. An example of a data delivery service is, for example, a navigation service. Such services communicate primarily with the respective user. A navigation service requires, for example, a map stored in a memory 110 which is connected to the execution container 100, and a current position of a mobile receiving device from the user. Communication with the service provider is not required. It is conceivable, however, that the service provider is communicated to what extent use was made of the data processing application in order to enable the service provider to charge the user for the services rendered. Data control services are, for example, remote control services for remotely controllable devices. An example of such a service is the ability to have a panoramic camera controlled by a remote user. In such a service, it is necessary for control signals from the user to reach the service provider via the execution container 100 in order to be able to control the camera.

Goods delivery services are well-known forms of online shops or, for example, printing services. These services actually require the user to provide private information, such as a delivery address or files to be printed.

The execution environment 102 or 104 associated with a respective data processing application is configured to exchange user input data and user output data with the data processing application 106 or 108. It is essential that all data exchange of the data processing application takes place via the assigned execution environment. Different computing applications executing in different execution environments of execution container 100 may not communicate with each other. This is ensured by the non-existence of shared memory and the structure of the communication interface 112 described in more detail below.

The communication interface 1 12 comprises a safety control unit 1 14, which in the present embodiment is designed in a distributed structure with two subunits 114.1 and 14.2. For the sake of simplicity, both subunits are also referred to below as a safety control unit. The safety control units 1 14.1 and 114.2 are connected to a respectively assigned execution environment 102 or 104 and monitor the data communication of the data processing application 106 or 108.

In particular, the security control unit 114 is configured to prevent any communication of the associated data processing application, if it is to occur with a communication endpoint external to the associated execution environment and if the data communication bypasses the associated execution environment. The security control unit 14 therefore ensures that all data communication of the data processing applications 106 and 108 with an external communication endpoint is via the associated execution environment. This means that the execution environment always has control over the appropriate data communication and can ensure that provided user input data is not improperly communicated externally. The security control units 114.1 and 114.2 contained in the security control unit 114 access first security agreements 118 and 120 which are present in the execution container 100 in file form and constitute an agreement between the provider of the respective data processing application 106 or 108 and the respective user. Since a data processing application can be executed for a large number of users, the execution container 100 has a corresponding number of first security agreements, whereby the first security agreement assigned to each user is used. On the one hand, the format of the first security agreement must be rich enough to allow for convenient handling, and on the other hand, it needs to be scarce enough to ensure that malicious code can not be integrated that can search user-related data and send it using legitimate messages. Furthermore, the format of the security of the first security agreement is defined such that the communication interface 1 12 of the execution container 100 can check whether a respective message is permissible or not. It is advantageous to use a code in the first security agreement, which allows only the transmission of predefined messages, so-called literals. In this case, the security control unit 114 may make a simple comparison of character strings to check whether a message is allowed or not. The security control unit 114 therefore checks the incoming and outgoing messages sent to it for their admissibility according to the respective security agreement. The security control unit 114 is designed to prevent such data communication of a respective execution environment with any communication endpoint external to the execution container. not defined by the corresponding first security agreement 118 or 120 as admissible.

The communication interface 1 12 also contains an access control unit 16. The access control unit 16 accesses second security agreements 1 19 and 121, which are present in the execution container 100 in file form and form an agreement between the respective user and the execution container. Since execution containers can be used by a large number of users, the execution container 100 has a corresponding number of second security agreements, wherein the second security agreement assigned to each user is used for each user. The access control unit 116 monitors the accesses to the memory 110 using the second security agreement.

Permitted messages are forwarded externally via a data access layer 122. The interface 122 controls the read-only accesses to the memory 1 10. In addition, 122 controls allowed communication with literals as well as communication with other containers.

For some applications, however, it makes sense to allow simplified communication of the execution environment with external application relative to the execution container. 1, an external application environment 124 is shown, which houses a data processing application (not shown here). For example, this may be the control of the panoramic camera mentioned above. In this case, the associated first security agreement 118 includes a number of control commands that may be exchanged between the execution environment 102 in the execution container 100 and the external application environment 124. Such literals can be easily checked by the access control unit 14 for their permissibility.

It may, but is not necessary, to check all user output data for its admissibility. In one embodiment, certain types of data are excluded from the exam. For example, in this embodiment be determined that data that serve to control a graphical user interface, are not subject to the test step. It can be determined, however, that this data may only be sent to that part of the container which is executed on the terminal of the service user, where it can be displayed unchecked.

The communication interface 112 thus ensures, in cooperation with the security control unit 14 and the data access layer 122, that only those messages are exchanged with external communication endpoints that are expressly declared permissible in the first security agreement and at the same time ensure that they are only addressed to the predefined recipients / communication endpoints are sent in the security agreement. It should be appreciated that the execution container 100 may accommodate a variety of different computing applications and may also serve a large number of users of different computing applications. Accordingly, the permissible data may change frequently according to the stored first security agreements. The communication interface 1 12 therefore forms a kind of rule machine that monitors and controls the communication of the execution environments with other communication endpoints according to the predetermined first security agreements.

The frequency of messages to be sent can also be limited by the security agreements or by predefined rules of the execution container. It is also possible to send orthogonal messages in unspecified order. This prevents information from being illegally encoded in messages.

An execution container 100 may also be operated by a service provider. In this case, it is important that the security rules that the execution container 100 dictates can not be changed by the owner of the execution container. The safety rules of the embodiment container 100 according to the invention are fixed and are monitored by the means described above. Additional protection can be provided by the execution container is designed not to instantiate itself if it is not the absolutely first component that is started eg in a Java Virtual Machine (JVM), or if a foreign security manager is already installed or the JVM has been modified. Preferably, the execution container is adapted to compare secure hash codes of all running modules within the current process with a set of saved hash codes to check whether the current code corresponds to the original code of the provider of the execution container. Such a hash check also ensures that classes such as Java classes in a JVM that access external resources are safe.

In order to prevent access of different data processing applications to one another in different execution environments, the safety control unit 14 may be designed in such a way that different Java class loaders are provided for different execution environments. Objects in different execution environments will not have access to instances of other execution environments in this way. Only the execution container or Java classes provided within the same execution environment can access. The security control unit 1 14 ensures that access to classes in other execution environments is not possible. Likewise, there is no shared access of different execution environments to the same memory.

The execution container 100 ensures a secure and complete elimination of data and the data processing application when the corresponding data processing application is no longer needed, or when the first security agreement is no longer valid. The application environments needed to execute byte code, that is, the Java Runtime Environment (JRE) and the .NET Common Language Runtime (CLR), include a concept called garbage collection. It then ensures that data that is no longer needed is deleted. The data processing applications themselves are eliminated in the same way when they are no longer needed. A class Definition can be cleared by a class debugger, which can be implemented, for example, in Java by its own class loader for the execution container This class loader solves the loading of a class as well as its removal when it is no longer needed becomes.

Fig. 2 shows the structure of a distributed execution container according to another embodiment of the invention. The structure of a distributed execution container 200 illustrated in FIG. 2 is based on the structure of the execution container 100 shown in FIG. 1. Therefore, corresponding elements of the distributed execution container 200 in FIG. 2 are provided with reference numerals that are different from the elements of FIG in the first digit, where instead of a "1" a "2" is included. In the present exemplary embodiment, the execution container 200 contains two partial execution containers 200.1 and 200.2. The structure of execution container 200.1, with the exception of the features described below, corresponds exactly to the structure of execution container 100 of FIG. 1. In addition to the functional units described above, communication interface 212.1 of sub-execution container 200.1 and communication interface 212.2 of the sub-execution container 200.2 channel ports 226.1 to 232.1 or 226.2 to 232.2 provided. Corresponding execution environments 202.1 and 202.2 as well as 204.1 and 204.2 communicate with each other in pairs via corresponding channels. The number of channel ports is not fixed. The sub-execution containers 200.1 and 200.2 are provided on spatially separate hardware that communicate with each other. For example, the sub-execution container 200.1 may be installed on a stationary server while the second sub-execution container 200.2 is installed on a PDA. The communication interfaces 212.1 and 212.2 are designed to channel-specifically encrypt the data communication running on each channel. In this way, it is ensured that the parts 206.1 and 206.2 that communicate between the communicating execution environments 202.1 and 202.2, which jointly execute parts 206.1 and 206.2 of a data processing application, communicate with each other without accessibility for third parties. In this way, it is possible to distribute the computational burden of a data processing application on multiple devices with limited resources. This makes it possible to use improved resources and more processing power. The sub-execution containers mutually identify themselves using appropriate authentication mechanisms to ensure that the overall execution container 200 is a secure execution environment.

By connecting the sub-execution containers 200.1 and 200.2 with each other, both parts can access the same user input data if this is covered by the respective first security agreement, even if the data is physically located only on one of the two sub-execution containers. Similarly, the data communication with execution environments also runs outside the execution container 200. The required messages may be requested from each of the two sub-execution containers and are first delivered to the sub-execution container that can establish the data connection with the external execution environment 224. They are transmitted internally encrypted. The distributed structure of execution container 200 is therefore transparent to an internal data processing application.

3 illustrates a negotiation step between a user and a service provider for establishing a security agreement. A proposal 302 to be negotiated, which is submitted by either the user or the service provider, is checked for acceptance by the other party, ie the user 304 or the service provider 306. If the security agreement can not be accepted according to the security preference 304.1 available to the user or the security preference 306.1 available to the service provider, an amendment to the agreement proposal is made in accordance with the respective security preference and submitted as a counterproposal. This is then checked by the other side for acceptance. This mechanism is repeated until there is a mutually acceptable agreement, which is then signed by both parties and sent to the execution container as a completed and signed security agreement 308. Not shown in Fig. 3 is a termination of the negotiation, which according to predetermined criteria, such as the duration of Negotiation or non-acceptance of required minimum preferences by the other party is made.

Claims

Patentaπsprüche

1. execution container for a data processing application of a service provider, with

at least one execution environment that is configured, the data processing application, which user input data for generating

Processing user output data, instantiating and executing in the form of executable program data, as well as exchanging the user input data and the user output data with the data processing application;

a communication interface connected to the execution environment and configured to receive user input data and to

Forward the execution environment and output user output data sent by the execution environment to outside of the execution container;

a security control unit connected to the communication interface and configured to prevent such data communication of the data processing application from any communication endpoint external to the execution environment whose communication path bypasses the execution environment; and

an access control unit connected to the communication interface and arranged to prevent such data communication of the execution environment with any relative to the execution container external communication endpoint, which is not defined as permissible by a first security agreement.

2. Execution container according to claim 1, with a relative to the execution environment external memory for user input data, which is connected via the communication interface with the execution environment, wherein the security control unit is designed to prevent direct access of the data processing application to the memory.

3. execution container according to claim 2, wherein the execution environment is adapted to read via the communication interface relative to the execution container external user input data and store a local copy of the external user input data in the memory.

4. The execution container according to claim 1, wherein the execution container includes a negotiation unit and a negotiation interface, and wherein the negotiation unit is configured to negotiate the first security agreement between an execution container and a service user through the negotiation interface according to a predefined negotiation protocol.

5. The execution container according to claim 1, wherein the execution container includes a negotiation unit and a negotiation interface, and in which the negotiation unit is configured, via the negotiation interface according to a predefined negotiation protocol, a second security agreement between the negotiation interface

To negotiate execution containers and a service provider or service user, including:

an address of at least one data memory external to the execution container, to which a read access of the execution container is admissible, or

User input data that is allowed read access by the execution container.

6. Execution container according to claim 2 or 3, in which the execution environment is designed to store user output data received from the data processing application in the memory.

7. execution container according to claim 2, wherein the execution environment is formed, after completion of the execution of the data processing application, a deletion in the memory stored user input data and user output data of the data processing application.

8. Execution container according to one of the preceding claims, wherein the execution environment is adapted, after completion of the execution of the data processing application to cause an elimination of the instantiated executable program data of the data processing application.

9. The execution container according to claim 1, wherein the security control unit is configured to check the presence of a criterion for terminating the validity of the first security agreement, and, in the presence of such a criterion, deletion of stored user input data and user output data from the data processing application cause.

10. Execution container according to one of the preceding claims, in which the first security agreement contains information about communication end points, message types or data accesses permissible with respect to the data processing application.

1 1. An execution container according to one of the preceding claims, with a plurality of execution environments, wherein the execution environments are adapted to prevent any communication between different data processing applications in relative to each other external execution environments within the execution container.

12. execution container according to one of the preceding claims, wherein the execution environment is formed on a received from the data processing application forth command out via the communication interface a specified in the command, selected from a set of predefined literals literal to a relative to the execution container external communication endpoint send.

13. Execution container according to claim 12, wherein the execution environment is adapted to send via predefined literals at most a maximum number T data bits, which is defined by

T = nx log ₂ L = f ^* t ^* log ₂ L

where n is the number of literals transferred, L is the total number of predefined ones

Literale is, f the frequency of the transmission of literals and t the duration of a session in which literals are transmitted.

The execution container of any one of the preceding claims, comprising at least one processor wherein the execution environment is adapted to vary a processor load according to a random time pattern that is independent of an actual load by the data processing application.

15. A distributed execution container, comprising first and second execution containers as claimed in any one of the preceding claims, wherein the first and second execution containers are connected via a communication channel for exchanging data and wherein the execution environment of each execution container is formed, opposite each other Identifying execution environment by suitable authentication mechanisms, and wherein the communication interfaces of the execution container are adapted to exchange data in encrypted form over the communication channel.

16. Execution container according to one of the preceding claims, in which the execution environment is formed by an application environment, in particular a Java runtime environment or a .NET runtime environment.

17. Execution container according to one of the preceding claims, in which the executable program data are in the form of bytecode.

18. Data carriers with executable program data which, when executed, form an execution container for a data processing application of a service provider according to one of the preceding claims.