DE102010040259A1 - Method for providing executable transfer program code for performing controlled transfer of data between domains, involves compiling executable transfer program code by workflow module, based on selected configuration parameter - Google Patents

Abstract

The method involves providing several modules such as location module, functional module and workflow module. The executable transfer program code is compiled by workflow module, based on selected configuration parameter. The workflow instance and secondary software modules for location and functional modules are selected. The transfer of program code is initiated, the program code is stored in a protected storage medium, and the program code is encrypted. Independent claims are included for the following: (1) transfer device; (2) security module; and (3) mobile transfer device.

Description

The invention relates to a method for providing an executable transfer program code for a transfer program for the controlled transfer of data between domains.

The invention further relates to a transfer method for the controlled transfer of data between domains.

The invention further relates to a transfer device for the controlled transfer of data between domains.

The invention further relates to a security module for providing and updating protected memory contents.

The invention further relates to a mobile transfer device for the controlled transfer of data between domains.

Data, especially digital data such as files, is often transferred between different domains. By transfer is meant here, for example, an import, export, exchange, a move or copy of data. Domains between which data is transferred are, for example, computer or computer networks, storage media or other IT infrastructures. It is a fundamental goal to keep such domains free of malicious software or malware, such as viruses, worms, Trojan horses, spyware, adware, etc. Since malicious software is often provided as a transferable file, there is a risk, especially when transferring data between domains, that malware is imported into a domain or exported from a domain during data transfer.

There are numerous software programs, such as anti-virus scanners or firewalls, which prevent the intrusion of malicious software into a domain or harmless or invade invaded malicious software.

A disadvantage of existing solutions is in particular that no complete protection against circumvention is guaranteed and despite the existing security software can reach malicious programs in a domain. Furthermore, an adaptation to individual conditions or requirements of an operator of a domain is often not possible or associated with a great effort. Furthermore, it is difficult or impossible to ensure that the security software itself was not infected by a malicious program. A particular problem continues to be the widespread use of mobile storage media and removable media such. As USB sticks, memory cards, CDs, etc., because it is very easy to transfer malicious software to network domains through these media.

It is therefore an object of the present invention to provide a method for providing an executable transfer program code and a transfer method which reduces or avoids the mentioned disadvantages.

• – Bereitstellen eines Vorrats verschiedener Module, wobei ein Modul einen ausführbaren Programmcode eines Teils eines Transferprogramms umfasst, wobei der Vorrat verschiedener Module umfasst:
• – mindestens ein Speicherort-Modul, wobei das Speicherort-Modul ausgebildet ist, Zugriff auf einen Speicherort zu ermöglichen,
• – mindestens ein Funktions-Modul, wobei das Funktions-Modul ausgebildet ist, Daten von einem ersten Speicherort auszulesen, eine Sicherheitsfunktion auf die Daten zu erbringen und die Daten an einen zweiten Speicherort zu schreiben,
• – mindestens ein Workflow-Modul, wobei das Workflow-Modul mindestens einen Konfigurationsparameter zum Steuern der Speicherort- und/oder Funktions-Module umfasst,
• – vorzugsweise mindestens ein Identitäts-Modul, wobei das Identitäts-Modul als gespeicherte Daten oder als Hardware ausgebildet ist,
• – vorzugsweise mindestens eine Referenz auf eine Aktualisierungsquelle,
• – vorzugsweise mindestens ein Sekundärsoftware-Modul,
• – Anbieten einer Auswahl von Konfigurationsparametern,
• – Zusammenstellen des ausführbaren Transferprogrammcodes durch
• – Instanziieren des mindestens einen Workflow-Moduls auf Basis der ausgewählten Konfigurationsparameter zu mindestens einer Workflow-Instanz
• – Auswählen von für die mindestens eine Workflow-Instanz erforderlichen Speicherort- und Funktions-Module,
• – ggf. Auswählen von für die ausgewählten Speicherort- und Funktions-Module erforderlichen Sekundärsoftware-Module,
• – ggf. Auswählen von für die ausgewählten Sekundärsoftware-Module erforderlichen weiteren Sekundärsoftware-Module,
• – Signieren des ausführbaren Transferprogrammcodes,
• – Schreiben des ausführbaren Transferprogrammcodes auf ein geschütztes Speichermedium,
• – Verschlüsseln des ausführbaren Transferprogrammcodes.

This object is achieved by a method for providing an executable transfer program code for a transfer program for the controlled transfer of data between domains, comprising the steps:

• Providing a stock of various modules, wherein a module comprises executable program code of a part of a transfer program, the stock of different modules comprising:
• At least one storage location module, wherein the storage location module is configured to allow access to a storage location,
• At least one functional module, wherein the functional module is designed to read data from a first storage location, to perform a security function on the data and to write the data to a second storage location,
• At least one workflow module, the workflow module comprising at least one configuration parameter for controlling the storage location and / or function modules,
• Preferably at least one identity module, wherein the identity module is designed as stored data or as hardware,
• Preferably at least one reference to an updating source,
• Preferably at least one secondary software module,
• Offering a selection of configuration parameters,
• - Compile the executable transfer program code
• Instantiating the at least one workflow module based on the selected configuration parameters for at least one workflow instance
• Selecting storage and function modules required for the at least one workflow instance,
• If necessary, selecting secondary software modules required for the selected storage location and function modules,
• If necessary, selecting further secondary software modules required for the selected secondary software modules,
• Signing the executable transfer program code,
• Writing the executable transfer program code to a protected storage medium,
• - Encrypt the executable transfer program code.

The inventive method provides that a transfer program for carrying out a transfer method for the controlled transfer of data between domains is provided, the executable transfer program code has been created in the inventive manner described here.

• – Es wird sichergestellt, dass der erzeugte ausführbare Transferprogrammcode keine Schadsoftware enthält und gegen Schadsoftware gesichert ist.
• – Es wird sichergestellt, dass der ausführbare Transferprogrammcode je nach Anwendungsumgebung bzw. Domänenverwalter einen individuellen Umfang aufweist, der auf die für diese spezielle Konfiguration minimal erforderlichen Programmteile reduziert ist.

Advantages of the method according to the invention for providing an executable transfer program code include the following:

• - Ensures that the generated executable transfer program code contains no malware and is secured against malware.
• - It ensures that the executable transfer program code has an individual scope, depending on the application environment or domain administrator, which is reduced to the minimum required program parts for this particular configuration.

The executable transfer program code provided with the method enables the secure execution of a transfer program for the controlled transfer of data between domains.

A controlled transfer of data between systems is understood here to mean a transfer which takes place in accordance with the transfer processes defined in accordance with the invention and is thus controlled and secure. In this case, a controlled transfer of data between systems according to the invention prevents unwanted data (for example malware) or data from being transferred in an undesired format. It is advantageous that not only the blocking of malware is made possible, but also that it is possible to ensure that only certain types of files / documents or only files / documents with certain properties are transferred or certain properties are changed by file transfer modifications. Documents are generated.

With the method according to the invention, a module supply is provided from which required or desired modules can be selected for an executable transfer program code to be created. This selection is made on the basis of configuration parameters, which are preferably selected or defined by a - authorized - user in accordance with the functions required for the application area or the domain management. In this way, the mapping of policies or policies of a domain operating organizational entity (e.g., a business or government agency) is possible. Furthermore, it is also possible to implement different policies for an organizational unit by means of different configurations, for example to be able to use different policies for different transfer points between domains. In a configuration, each of the organizationally desirable, acceptable or allowed transfer operations (referred to herein as legitimate transfer operations) can be defined. These legitimate transfer processes, which are defined from an organizational point of view, are converted in the process according to the invention into transfer processes which are designated here legally. Legal transfer operations are the transfer operations possible when executing the transfer program code. In this case, it is preferred that the method according to the invention, in particular the selection of configuration parameters, permits the most accurate mapping of the legitimate transfer processes to the legal transfer transactions actually possible in the executable transfer program code.

The offering of the selection of configuration parameters can be done, for example, by presenting a selection in a web browser in which a user can select or freely enter various configuration parameters from a given selection.

The configuration parameters may include, in addition to information regarding the legitimate transfer operations, information about the execution environment in which the transfer program code is to be executed, such as network configurations or (sender) email addresses.

Furthermore, certain configuration parameters that are not changeable by a user or can be overridden can also be preset in the method.

On the basis of the selected or predetermined configuration parameters, the required modules are then selected from the module supply and instantiated according to the configuration parameters according to the inventive method.

The modules present in the module stock are executable program codes which represent parts of a transfer program, for example individual, executable steps of a transfer method. The pool of function, storage and workflow modules and the resulting combination options together form a space for possible transfer processes.

The supply preferably contains at least one module of the various module types, but preferably two or more, in particular a plurality of respective modules.

A functional module is an executable program code that allows data to be read in from a first memory location, to provide a security function, and to write the data to a second memory location. The security function to be performed may preferably include checking, verifying, modifying, normalizing or converting a file.

For example, testing may include classifying data for a condition, where possible conditions may be, for example, benign, warning, malicious, or unknown.

The security functions may preferably be used to change the file format, representation of the file (its syntax, eg storage as a byte sequence) and / or meaning (the semantics of the file).

For example, by means of a security function, the representation (in the sense of storing the file as a byte sequence) of a file can be changed, but its (content) meaning remains the same or is maintained.

A "modify" security function generally refers to changing a file, such as its appearance and / or meaning. It is preferable to distinguish between meaningful modifications and meaning-changing modifications. Examples of meaningful modifications include removing a change history from a Word file, setting the author information to default, or removing active content (scripts).

A meaningful modification is, for example, the insertion of a comment line "checked on XXX" into a program source code. The meaning remains the same (in the sense of the program that results from the translation), but the file is changed in its memory form.

A security function "normalize" preferably designates a meaning-preserving change of a file into a certain predefined format, its "normal form". Since file formats are usually very flexible, the same information can be represented by very many (as a byte sequence) different files. "Normalize" means to define a procedure to put files in their "normal form". In a rigorous, mathematical definition, "normalizing" means assigning exactly one representation to each possible meaning, and bringing all the files of that meaning into exactly that form in the course of normalization. In the applied case in IT, however, under normalization, it is understood that all files that were brought into normal form have certain properties after normalization.

For example, with program source code, normalization could remove all comment lines and insert a copyright header at the beginning of the file. All normalized files then have these two properties after normalization (no comments, added copyright header). However, they may differ, for example, with respect to blank lines / characters, and therefore do not represent the "strict" normal form. The meaning is the same, but the representation (due to the blank line / character differences) is not. For example, two different source code files may still result in the same program while translating.

A security function "convert" preferably designates the rewriting of a file into another file format, for example the conversion of a file from the Microsoft Word format to the OpenOffice Writer format. Preferably, converting is primarily aimed at getting a file into a new, desired format. Secondary goal is often a (not necessarily complete) meaning retention: If the desired format does not have all the representation / meaning possibilities of the source format (eg when converting web pages to Microsoft Word), this change in meaning is accepted during the conversion.

Two or more function modules can be chained, i. H. that, for example, a first function module "Check" is concatenated with a second function module "Convert". In such a case, only the first functional module reads data from a first memory location, and only the last functional model writes the data to a destination memory location. The first function module writes the data into the second function module and the second (in this example at the same time the last) function module reads in the data from the previous function module.

A functional module is preferably further designed such that the execution, in particular the reading in and writing of data and the provision of the safety function, can be controlled by one or more configuration parameters.

Further preferably, characteristic user data are stored for each functional module, which in the execution of the functional module be used. Characteristic user data are, for example, antivirus signatures for a function module with an antivirus function. In the case of the method according to the invention, current user data are preferably used in the provision of an executable transfer program code.

A storage module is configured to allow access to one or more types of storage (eg, memory cards, CD media, network drives) when executed.

Multiple memory modules may also cooperate to execute, for example, when a memory module requires access to one or more other memory locations as it executes. These other storage locations may then be provided by additional storage location modules. Alternatively, these other storage locations may be provided by hardware components included in an execution environment for executing the transfer program code. For example, a storage location module that provides access to a USB flash drive requires access to a module that provides USB communication, and this module, in turn, has access to USB hardware.

Storage locations may be "technical" storage locations (eg storage media) or "logical / abstract" storage locations, for example when directly integrated into other payload applications such as document management systems, incident handling or customer care systems where the data is stored in them other useful applications are written and processed by them.

Each storage module provides a distinctive (but possibly completely or partially empty) set of configuration parameters. The configuration parameters are preferably at least partially selectable / changeable by a user. Furthermore, it may be preferred that storage location modules, such as, for example, workflow modules, also contain other configuration parameters that can not be viewed / changed by a user. Each concrete instantiation of these parameters describes a specific storage location of the corresponding type, called a storage location reference. Each location module can store any number of location references. For example, a location module for accessing network drives may include as configuration parameters a server name and a path. A concrete pair of server name and path designates an individual network drive.

Concrete instantiation of the configuration parameters may also include one or more "unspecified" configuration parameters. These "unspecified" configuration parameters are preferably determined when the transfer program code is executed, for example by a request to a user to enter the parameters. For example, user name and password for accessing a network drive may be marked as "unspecified" and queried by the user upon execution of the transfer program code.

A workflow module, when executed, connects storage location and function modules according to the configuration parameters. By means of these configuration parameters, the memory location and function modules and, if appropriate, their concatenation and preferably further execution properties of the transfer program are controlled.

In addition to the configuration parameters to be selected or determined by a user, the configuration parameters of a workflow module furthermore preferably contain a set of hidden configuration values that can not be changed by a user, which together with the user-definable configuration values in the workflow execution for the parameterization of Storage location and function module can be used.

A workflow module contains a selected set of storage location modules that define source or destination storage locations, as well as at least one functional module, but preferably an ordered list of functional modules to be linked. Alternatively, the workflow module contains references to the storage location and function modules to be used.

For example, the transfer operations depicted in the respective workflow modules may be more "technical" operations, such as: For example, checking a removable disk for malicious software contained therein, or rather "logical" operations such as reading completed form files to start a specific management process or reading print data into an order system of a print shop. The type of transfer operations mapped in a workflow depends on the application area, the users, and the domain-managing organizational unit. For example, for a public customer organization, the transfer operations depicted in the workflows are preferably those transfer operations that are required for the services that the organization offers to its customers.

The module store of the method according to the invention preferably contains at least one identity module. An identity module makes it possible for an individual instance of software that is configured to carry out the method according to the invention for Providing executable transfer program code, identifying and enabling it to be identified and authenticated to users and to network connections. The identity module may be in the form of stored (possibly program portion executable) data or as a hardware module. Preferably, an identity module for an identification occasion individually provides authentication data, which in turn preferably depend on previously requested event-specific data (so-called challenge / response). Examples include stored symmetric crypto keys, asymmetric key / certificate pairs or hardware crypto modules that contain such keys or certificates. An identity module can be permanently connected to a hardware required for carrying out the method according to the invention or can be temporarily introduced there by a user, for example as part of configuration work.

The module store of the method according to the invention preferably contains at least one secondary software module. A secondary software module is used to provide the function modules with the secondary software they need to perform their function. Such secondary software are, for example, programs, libraries, drivers or user data. Preferably, the secondary software modules are organized into groups, and further preferably to each of the groups are stored references to network resources by means of which the secondary software modules are updated, for example to make system updates and patches.

The module store of the method according to the invention preferably contains at least one reference to an updating source. A reference to an updating source for one or more of the secondary software modules and, if applicable, their user data indicates which publication source is to be used for updating the modules and possibly payload data. Preferably, a list of references to update sources is stored. Further preferably, for each type of module, i. H. for the functional modules, storage modules, workflow modules, identity modules and / or software modules and for the payload each a list of network references and preferably still a stock of cryptographic material stored. Each of these network references is a publication source from which current module or user data versions can be obtained. The cryptographic material identifies trusted sources and, when performing an update, allows verification of data integrity and authorization of the source. In this way, it can be ensured that when updating the modules or user data, only data from trustworthy sources are read in and, moreover, that the read-in data are not manipulated in order to prevent the import of malware into the modules or user data.

Based on the configuration parameters, which are preferably partially selected or determined by a user and partly predetermined and can not be changed by a user, a specific selection from the modules is made from this provided supply of different modules and instantiated on the basis of the configuration parameters. At least one workflow module is instantiated; however, preferably several workflow instances are generated. A workflow instance represents a legitimate transfer process provided as executable transfer program code. When a set of workflow instances are created, they represent a set of legitimate transfer operations that are provided in their entirety as executable transfer program code for a transfer program. A workflow instance includes a workflow module and associated configuration values used to run the workflow module. Furthermore, the workflow instance preferably contains references to (instantiated) modules that are required for the execution of the workflow or transfer process. Each reference can be assigned further configuration values (in particular authentication information, such as user name and password) with which references can be further specified.

According to the inventive method, the executable transfer program code for a transfer program from the at least one workflow instance and associated function, storage location, and secondary software modules is compiled based on the configuration parameters, wherein the executable transfer program code independently (ie without further software) on an execution environment (Hardware platform) can be executed.

By providing the executable transfer program code that is executable without further software, the method of the invention makes it possible to execute the executable transfer program code in an execution environment that is free of further software, thus reducing the risk that the transfer program itself will be affected by malware or even completely excluded.

By means of the configuration parameters, in particular the configuration parameter selected by a user, a provided executable transfer program code can be assigned to a specific execution environment, for example a specific hardware platform, and their environment and, for example, existing communication interfaces are tuned.

In particular, it is an advantage of the method according to the invention that, based on the selected configuration parameters, only the minimum required program codes of the parts of a transfer program are combined to form an executable transfer program code which is required for the corresponding configuration. This is done according to the invention by a recursive selection of the required modules, starting from the at least one workflow instance. For the workflow instances, the corresponding workflow modules and the memory location and function modules referenced or required therein are selected. If secondary software is required for proper operation of the selected storage and function modules, preferably only appropriate secondary software modules are selected. In a further step, it is preferably checked for the selected secondary software modules whether these in turn require further, other secondary software modules for a correct function. If so, these other secondary software modules are preferably also selected. This stepwise resolution of dependencies according to the invention prevents inclusion of modules that are not needed directly or indirectly to perform the legal transfer operations.

When selecting the modules, the most current available version is preferably selected in each case via the stored update sources. Furthermore, it is preferred that the modules stored in the storage are also updated via the update sources. In this way it can be ensured that at the time of providing an executable transfer program code a real-time updated state of the modules is used and all available at this time (security or functionally relevant) bug fixes are included in the created transfer program code.

The executable transfer program code thus composed is signed. In this case, preferably individual execution levels (boot loader, kernel, system environment) are signed separately and added additional program code for a concatenated runtime verification of the levels. The signature is preferably arranged so that parts of the entire transfer program code are included in a (partial) signature and no part of the transfer program code, such as a module or payload, can be changed without violating a cryptographic signature. The signature preferably takes place using the cryptographic material from the identity module. Signing the executable transfer program code enables a comprehensive validation of its integrity and ensures that the transfer program code was created by a trusted system or trusted source and by a trusted process.

The signed executable transfer program code is written to a storage medium that is preferably suitable for booting an execution platform (eg, a CD or DVD) and is preferably read-only, such as a CD-ROM / DVD-R.

In a last step of the method according to the invention, the executable transfer program code is encrypted. Preferably, in an asymmetric encryption, the public key of an identity module of a planned execution environment is used for this purpose. In this way, it can be ensured with the method according to the invention that the provided transfer program code can only be executed in a specific, trusted and unchanged execution environment.

An executable transfer program code provided by the method according to the invention for a transfer program for the controlled transfer of data between domains thus enables a user to execute only the legal transfer operations that are combined from selected function, storage location, workflow, and secondary software modules derived from the legitimate transfer transactions. All other transfer operations can not be performed, either by dialing or by manipulation / corruption of an execution environment.

The following advantages also result from executing the provided executable transfer program code: Users are allowed only those input and output operations needed for the legal transfer operations needed devices. Furthermore, preferably only the operations required for this purpose are accepted and executed. An executable transfer program code provided by the method according to the invention furthermore makes it possible for an execution environment (hardware platform) to carry out a step-by-step, secure start of the transfer program, starting from a trust anchor.

• – Bereitstellen eines ausführbaren Transferprogrammcodes, vorzugsweise mittels eines zuvor beschriebenen erfindungsgemäßen Verfahrens zum Bereitstellen eines ausführbaren Transferprogrammcodes,
• – Starten eines Transferprogramms durch Ausführen des Transferprogrammcodes,
• – Prüfen, ob das gestartete Transferprogramm einem Referenzzustand entspricht, – Falls das das gestartete Transferprogramm nicht dem Referenzzustand entspricht:
• – Normalisieren des Transferprogramms und Wiederholen der Prüfung,
• – Falls das gestartete Transferprogramm dem Referenzzustand entspricht:
• – Anbieten einer Auswahl von Transfervorgängen,
• – Ausführen eines ausgewählten Transfervorgangs,
• – Zurücksetzen des Transferprogramms in den Referenzzustand.

The object is further achieved by a transfer method for the controlled transfer of data between domains, comprising the steps:

• Providing an executable transfer program code, preferably by means of a previously described method according to the invention for providing an executable transfer program code,
• Starting a transfer program by executing the transfer program code,
• - Check whether the transfer program started corresponds to a reference state, - If the transfer program that has been started does not correspond to the reference state:
• - normalize the transfer program and repeat the check,
• - If the transfer program started corresponds to the reference state:
• - offering a selection of transfer transactions,
• - execute a selected transfer process,
• - Resetting the transfer program to the reference state.

For the transfer method according to the invention, an executable transfer program code is first provided. Preferably, it is provided on a protected storage medium to prevent changes or manipulations of the transfer program code.

According to the transfer method according to the invention, after starting a transfer program and before executing transfer operations, it is checked whether the started, d. H. ongoing transfer program corresponds to a reference state, d. H. has certain properties.

The reference state is preferably checked / restored based on system properties stored in the workflow, storage, functional modules. Preferably, each module is called in the course of the check / restore of the reference state and prompted to check or restore system properties and properties of a respective reference state. Preferably, in response to an initiated check, the respective module reports whether its own and system state are in the reference state, or in response to a restore request, whether the restore was successful. The check and restore prompts are preferably initiated by a particular, always-existing secondary software module, which preferably displays a main menu and the workflow selection.

If the check reveals that the transfer program is in the reference state, one or more transfer operations are provided to a user for selection, and upon selection by the user, the selected transfer operation is performed. The transfer processes used are preferably the transfer processes described above. In particular, it is preferred that the transfer operations include one or more of the security functions described above with respect to the functional modules.

If the program is not in the reference state, d. H. If the exam has a negative result, the transfer program is normalized. In particular, normalization includes the removal of all traces or data from previous transfers and may include a restart or cold start of the transfer program. After normalization, the check is made again as to whether the (newly) started transfer program corresponds to the reference state.

In this way, it is ensured that transfer processes are only carried out if the transfer program started has certain properties or fulfills certain conditions, so that a secure and controlled transfer of the data is ensured. Changes, manipulations or other damage to the executable transfer program code or the started transfer program are preferably detected in the check on the reference state and lead to a normalization of the program.

The actual transfer process is initiated in the transfer process after the (successful) check for the reference state by offering a selection of transfer transactions. A user can select a transfer process to be performed from the offered transfer transactions. Preferably, a user may also select a source and / or destination location. Which options a user has is preferably predetermined by the executable transfer program code and the legal transfer operations depicted therein. In particular, where particularly preferred, the executable transfer program code has been provided by means of a method of providing executable transfer program code described above, the user-selectable options are determined by the configuration parameters in this delivery method.

The transfer method is preferably developed by carrying out a selected transfer process comprising the determination of specific parameters for the selected transfer process. The parameters are determined, for example, via a user dialog or can be derived from properties, for example, of the data to be read or of the removable data medium used.

When performing a selected transfer operation, authentication is preferably performed when accessing certain storage locations. Preferably, the authentication data required for this purpose are stored in the executable transfer program code, are determined by a user query or by an execution environment executing the transfer program code with a hardware identity module or from other sources, for example network resources.

Upon completion of a transfer operation, the system is automatically restored to the trusted reference state, which is accomplished, for example, by data deletions and / or a reboot or cold start of the transfer program. Thereafter, the transfer process begins again with the step of checking whether the started transfer program corresponds to a reference state. In this way, the transfer process can be carried out in a loop, so that repeated transfer operations can be performed.

In the transfer method according to the invention, in particular when the executable transfer program code has been provided according to the inventive method for providing an executable transfer program code, based on the knowledge that, in contrast to known security measures in which a provided work environment is open, communicative and flexible, although certain Negative or harmful classified system operation and communication processes are prohibited, however, neutral and positive processes are allowed. By contrast, according to the invention, by specifying a selection of possible transfer processes, a user is exclusively allowed to perform these positive and all operations and access / access options to be performed by the user (system access, actions, communications, transfer operations) are reduced to a positively predetermined, limited number of transfer operations , The associated loss of flexibility is offset by the safety gain associated with the methods of the invention.

• – Anstoßen der Aktualisierung,
• – Vorbereiten der Aktualisierung,
• – Prüfen der empfangenen Daten,
• – Beenden der Aktualisierung.

The transfer method is preferably further developed by the step of updating the provided executable transfer program code, the updating comprising the steps of:

• - initiate the update,
• - prepare the update,
• - checking the received data,
• - Finish the update.

The transfer method according to the invention starts with a provided executable transfer program code, which is preferably provided on a protected storage medium. This protected storage medium can be, for example, a CD or DVD that can only be written once. This ensures the security and integrity of the executable transfer program code. However, updating the executable transfer program code requires replacement of the protected non-rewritable storage medium.

However, according to the embodiment, a protected rewritable storage medium may be used which allows updating of the executable transfer program code without replacement of the protected storage medium. With the preferred method development, a secure and integer provision of an executable transfer program code on a changeable, rewritable storage medium is thus made possible.

• – das Anstoßen der Aktualisierung einen oder mehrere der folgenden Schrille umfasst:
• – Anfordern einer Aktualisierung durch einen Benutzer,
• – Anfordern einer Aktualisierung nach Ablauf einer vorbestimmten Zeit seit einem Ereignis,
• – Prüfen der Verfügbarkeit einer aktualisierten Version des ausführbaren Transferprogrammcodes und Anfordern einer Aktualisierung wenn die Prüfung ergibt, dass eine aktualisierte Version verfügbar ist,
• – und/oder das Vorbereiten der Aktualisierung einen oder mehrere der folgenden Schritte umfasst:
• – Signalisieren der Bereitschaft, eine aktualisierte Version des ausführbaren Transferprogrammcodes zu empfangen,
• – Empfangen einer aktualisierten Version des ausführbaren Transferprogrammcodes,
• – Speichern der aktualisierten Version des ausführbaren Transferprogrammcodes,
• – Signalisierung der Beendigung des Empfangs,
• – Beenden des Empfangs,
• – und/oder das Prüfen der aktualisierten Version des ausführbaren Transferprogrammcodes einen oder mehrere der folgenden Schritte umfasst:
• – Verifizieren einer digitalen Signatur der aktualisierten Version des ausführbaren Transferprogrammcodes,
• – Überprüfen eines Zertifikats der aktualisierten Version des ausführbaren Transferprogrammcodes,
• – Überprüfen, ob der Zeitstempel und/oder eine Versionsnummer der aktualisierten Version des ausführbaren Transferprogrammcodes neuer ist als der Zeitstempel und/oder eine Versionsnummer einer vorher verwendeten Version des ausführbaren Transferprogrammcodes,
• – Verwerfen der aktualisierten Version des ausführbaren Transferprogrammcodes bei einem negativen Ergebnis mindestens einer der Prüfungen der vorhergehenden Schritte,
• – Akzeptieren der aktualisierten Version des ausführbaren Transferprogrammcodes bei einem positiven Ergebnis aller Prüfungen der vorhergehenden Schritte,
• – und/oder das Beenden der Aktualisierung einen oder mehrere der folgenden Schritte umfasst:
• – Signalisieren eines Ergebnisses der Aktualisierung,
• – Bereitstellen der aktualisierten Version des ausführbaren Transferprogrammcodes.

Updating the prepared executable transfer program code includes the above four sub-steps. These four substeps are preferably developed as follows by:

• - triggering the update includes one or more of the following:
• Requesting an update by a user
• Requesting an update after a predetermined time has elapsed since an event,
• Checking the availability of an updated version of the executable transfer program code and requesting an update if the check reveals that an updated version is available,
• - and / or preparing the update includes one or more of the following steps:
• Signaling the readiness to receive an updated version of the executable transfer program code,
• Receiving an updated version of the executable transfer program code,
• Storing the updated version of the executable transfer program code,
• - signaling the completion of the reception,
• - finish the reception,
• And / or checking the updated version of the executable transfer program code comprises one or more of the following steps:
• Verifying a digital signature of the updated version of the executable transfer program code,
• Checking a certificate of the updated version of the executable transfer program code,
• Checking whether the time stamp and / or a version number of the updated version of the executable transfer program code is newer than the time stamp and / or a version number of a previously used version of the executable transfer program code,
• - discarding the updated version of the executable transfer program code in the event of a negative result of at least one of the checks of the preceding steps,
• Accepting the updated version of the executable transfer program code if the result of all checks of the preceding steps is positive,
• - and / or completing the update includes one or more of the following:
• - signaling a result of the update,
• - Providing the updated version of the executable transfer program code.

The preferred development of the transfer method is preferably carried out on a transfer device according to the invention described below, which preferably has a security module also described below. If a safety module is referred to in the following description of the further development of the transfer method, reference is made to the description section below for a more detailed description of the security module.

An update may have various triggers, for example, a user may request an update, may have passed a certain time after a particular event, in particular a previous update, or since a reboot, or a periodic review has revealed that an updated version of the executable Transfer program codes is available.

The subsequent performance of the update, in particular the preparation of the update, the checking of the updated version and the termination of the update, take place independently of the trigger of the update.

To prepare for the update, the readiness to receive an update is initially signaled, preferably by the security module, to a system performing the transfer process. Preferably, this ensures that there is enough storage space to store an updated version. Subsequently, an updated version of the executable transfer program code is downloaded from a source, preferably an authenticated one, wherein the received updated version is preferably digitally signed and has a time stamp and / or a version number.

The downloaded updated version of the executable transfer program code is then stored, preferably in the non-"active" marked subarea of a security module.

Subsequently, it is signaled that the reception has ended. Then the data reception is terminated, preferably by the security module. The update is thus prepared.

In the following, again preferably by the security module, the updated version is checked. When using a security module, preferably, for the duration of the check, any communication with an execution environment executing the transfer method is temporarily interrupted. The check of the updated version preferably comprises several steps, with a negative check result already leading to the abort of the update. The verification steps preferably include verifying the digital signature, verifying that the digital signature is from an issuer whose certificate has been deposited in a trusted certificate store, and / or verifying whether the time stamp and / or version number of the received version are newer than that of a previously used version. Only if all test steps are completed positively will the received updated version of the executable transfer program code be accepted.

To terminate the update, it is preferred, in particular if a security module is used, that the memory area containing the newly received data be marked as active. Further preferably, the result of the update is signaled; preferably so that a user can see the signal. Preferably, a successful update or an unsuccessful update is distinguishably displayed. When using a security module, the communication with the execution environment carrying out the transfer process is then preferably restored.

Finally, the updated version of the executable transfer program code is provided so that the transfer process begins again with the start, preferably a cold start or restart, of the updated executable transfer program code and continues as described above.

In particular, it is preferred that a user is signaled that all prerequisites for a secure performing of the transfer process (for example, by a green display) or that a secure transfer method is not possible or not recommended (for example, by a red indicator). The latter may be the case, for example, if the protected storage medium is not in a trustworthy state, an update has been triggered but not made in a certain time, if there is no valid and signed executable transfer program code, if a validity period of the executable transfer program code has expired, if a certificate (or its issuer certificate verifying a digital signature) has expired or if verification of the executable transfer program code could not be verified at startup.

• – einen Prozessor und einen Hauptspeicher,
• – eine geschützte Schnittstelle zum Auslesen eines geschützten Speichermediums,
• – ein Transfervorrichtungs-Identitätsmodul umfassend kryptographisches Material,
• – einen Vertrauensanker,
• – mindestens eine Schnittstelle zum Auslesen von Speichermedien oder Wechseldatenträgern,
• – mindestens eine Kommunikations-Schnittstelle zur Kommunikation mit Speicherorten,
• – mindestens eine Interaktionsschnittstelle zur Kommunikation mit einem Benutzer.

The object is further achieved by a transfer device for the controlled transfer of data between domains, comprising

• A processor and a main memory,
• A protected interface for reading a protected storage medium,
• A transfer device identity module comprising cryptographic material,
• - an anchor of trust,
• At least one interface for reading from storage media or removable media,
• At least one communication interface for communication with memory locations,
• - At least one interaction interface for communication with a user.

The transfer device according to the invention is in particular designed to carry out a transfer method according to the invention and represents an execution environment with which a transfer method according to the invention is preferably carried out. A transfer device according to the invention serves as a kind of "security lock" between domains and enables the secure execution of transfer operations.

In addition to basic components, the transfer device has a protected interface for reading out a protected storage medium. An executable transfer program code is preferably stored on the protected storage medium. The transfer device can start a transfer process by reading out and executing the transfer program code. This interface is preferably protected against (unauthorized) data modification as well as (unauthorized) physical access (change / exchange) from the outside. For example, the interface may be formed as a CD or DVD drive, which is secured with a lock. Providing the protected interface for reading out a protected storage medium ensures that a restart or cold start of a program read from the protected storage medium always leads to a trustworthy program state.

Furthermore, the transfer device comprises a transfer device identity module containing cryptographic material, for example a certificate and one or more private keys. The cryptographic material is preferably used for decrypting data, signatures and for authentication in network accesses. Preferably, the transfer device identity module is a hardware component that is fixedly connected to the transfer device and does not allow for readout of the cryptographic material so that preferably all cryptographic operations must take place on the transfer device identity module itself.

The transfer device according to the invention also has a trust anchor, which allows a secure initialization of a program to be executed on the transfer device. The trust anchor is preferably a hardware property, such as a defined starting point of a processor (CPU), which ensures that the start of a program to be executed by the transfer device always starts the interpretation of the executable program code in the same way. In this way it is ensured that the execution of the program code is trusted initialized and a gradual system start is performed with a concatenated verification of signed program code parts, so that a program to be executed is in a trusted state after the system startup.

The at least one interface for reading from storage media or removable data carriers represents the interface to a first domain, the communication interface for communication with storage locations is an interface to a second domain, wherein between these domains a controlled data transfer by means of the device according to the invention takes place.

The transfer device according to the invention further has an interaction interface for communicating with a user in order to enable the user inputs or queries required in the execution of a transfer method on the transfer device. Preferably, the interaction interface is designed to be reduced so that it only allows for the necessary for the execution of a transfer program interactions / inputs / outputs. For example, instead of a keyboard / mouse combination, it is preferable for the user to provide only a touch screen that supports the inputs Interaction capabilities of a user largely reduced to the input of command alternatives via dedicated buttons. If text has to be entered, it is preferred that the touch screen is designed to display and then remove a screen keyboard with a reduced key layout in these situations. Overall, it is preferred that the interaction interface is designed in such a way that the user is provided with only minimal interaction possibilities, limited to the necessary interactions, and whose scope and time availability is limited as far as possible.

• – einen nicht-flüchtigen Nutz-Speicherbereich, wobei der Nutz-Speicherbereich einen ersten und einen zweiten Teilbereich aufweist,
• – eine Markierung, die angibt, welcher der beiden Teilbereiche eine Markierung als „aktiv” trägt,
• – einen Krypto-Prozessor zum Ausführen von kryptographischen Operationen,
• – einen geschützten Speicherbereich zum Abspeichern mindestens eines Zertifikats,
• – eine Echtzeit-Uhr,
• – vorzugsweise einen physikalischen Interaktions-Mechanismus,
• – vorzugsweise eine physikalische Status-Anzeige,
• – eine Schnittstelle zum Auslesen des Sicherheitsmoduls durch ein System.

The object is further achieved by a security module for providing and updating protected storage contents,
full

• A non-volatile useful memory area, the useful memory area having a first and a second partial area,
• A marking which indicates which of the two subareas carries a marking as "active",
• A crypto processor for performing cryptographic operations,
• A protected memory area for storing at least one certificate,
• - a real-time clock,
• Preferably a physical interaction mechanism,
• Preferably a physical status indicator,
• - An interface for reading the safety module by a system.

The security module according to the invention is preferably designed to be connected as a protected storage medium to a protected interface for reading out the protected storage medium of a transfer device according to the invention, wherein an executable transfer program code provided by the method described above is preferably stored on the security module according to the invention.

The security module according to the invention advantageously makes it possible, on the one hand, to provide a protected storage medium which ensures that a program started from this storage medium starts in a trustworthy state, while at the same time enabling an updating of the executable transfer program code and thereby ensuring that the updating of one trusted, authenticated source, and the integrity of the updated executable transfer program code is ensured.

The security module according to the invention represents an extended protected storage medium with update functionality, which can be used instead of a read-only medium, such as a CD-ROM. The nonvolatile useful memory area of the security module is divided into a first and a second subarea, wherein each subarea is preferably large enough to accommodate at least once a complete executable transfer program code. Furthermore, the security module has a marking with which it is possible to indicate which of the two subregions is active. The tag is preferably stored in a protected storage area. Further preferably, this may be the same protected memory area for storing the at least one certificate. A preferred embodiment provides, for example, that the crypto-processor offers in its hardware a specially read-out and manipulation-protected memory area in which applications, both certificates and, to a lesser extent, further internal administration data (such as the tag) are stored can be. Preferably, a change of the marking is not provided by a process other than that described here and is furthermore preferably prevented by the security module according to the invention.

The crypto-processor is preferably designed to perform cryptographic operations, such as data hashing and verification of asymmetrical digital signatures, in a hardware-accelerated manner.

A protected memory area in the security module is used to store at least one certificate.

The certificates preferably contain information about trustworthy data sources that are authorized to import new software packages. Preferably, a certificate is the public part of a cryptographic key, with the name of the owner and other, similar identity information and a validity period.

The certificate makes it possible to verify a digital signature created with the associated secret key. In the case of the lock, the secret key is in the identity module of the management system, which is entitled to send new software packages to the lock.

By means of the method described above for providing an executable transfer program code, the program code is preferably signed with a secret key. The security module preferably has an associated certificate stored. When a new version of the executable transfer program code is sent as part of an upgrade, it checks Security module, preferably, whether a valid digital signature with one of the internally stored certificates has been made. If so, the new version of the executable transfer program code is accepted.

The protected memory area for storing at least one certificate is preferably protected against manipulation, since a certificate deposited by an attacker would then enable the acceptance of a program code of the attacker.

For example, the real-time clock of the security module is used to verify timestamps.

The security module according to the invention preferably has a physical interaction mechanism. The physical interaction mechanism may be configured, for example, as a switch, button, or lever and is preferably protected on the security module or, if the security module is incorporated in a transfer device, secured to the transfer device so that the interaction mechanism is preferably accessible only to authorized persons (e.g. by having to open a lock to reach the interaction mechanism).

The security module according to the invention preferably has a physical status display. For example, a physical status indicator may be implemented as an optical display or signal lamp, and is preferably arranged to indicate a condition or function to a user. Preferably, the display is labeled accordingly.

Furthermore, the security module has an interface via which the security module can be read out by a system or a device. Preferably, this interface is designed such that the security module can be read by a protected interface of a transfer device according to the invention for reading a protected storage medium.

The security module according to the invention is preferably designed to mark the subarea as "active" in which a current executable program code, preferably an executable transfer program code, is stored. The executable program code can be read out and started from the section marked as "active".

The security module, in particular the crypto-processor, is preferably also designed, each time an executable program code is started from the security module, the module verifies the digital signature of the started program code by means of the certificates stored as trusted.

Furthermore, the security module is preferably designed to display a failed verification via the physical status display. Furthermore, the security module is preferably designed to block access to the subarea with the non-verified program code in the event of a failed verification.

The security module can be developed in that the useful memory area is designed in such a way that only one of the two partial areas that carries a marking as "active" can be read out at the interface for reading out the security module by a transfer device.

As a result, it can be ensured that the security module presents itself as a regular storage medium of the size of one of the two subareas in relation to a transfer device which reads out the useful storage area of the security module. If, for example, the memory module internally has a memory of 4 gigabytes and this is divided into two memory areas of two gigabytes each, the security module presents itself as a storage medium of the size of 2 gigabytes. Preferably, the interface for reading out the security module by a system as a standard interface, such as a USB Mass Storage Class, formed, which can be preferably integrated into a normal boot process (boot) of a system or a transfer device and for a trust anchor a transfer device is accessible. In this way, the security module, for example, emulate a 2 gigabyte USB stick.

The security module can be developed by virtue of the security module comprising a secure, separate maintenance channel via which a transfer device connected to the security module can be switched off, in particular disconnected from the power, or a program restarted on the transfer device can be restarted, in particular if one of the Security module performed verification step failed.

• – einen Prozessor und einen Hauptspeicher,
• – ein erfindungsgemäßes Sicherheitsmodul wie oben beschrieben
• – ein Transfervorrichtungs-Identitätsmodul umfassend kryptographisches Material,
• – einen Vertrauensanker,
• – mindestens eine Schnittstelle zum Auslesen von Speichermedien oder Wechseldatenträgern,
• – mindestens eine Kommunikations-Schnittstelle zur Kommunikation mit einem PC-System,
• – vorzugsweise eine Anzeigevorrichtung.

The object is further achieved by a mobile transfer device for the controlled transfer of data between domains, comprising

• A processor and a main memory,
• - An inventive security module as described above
• A transfer device identity module comprising cryptographic material,
• - an anchor of trust,
• At least one interface for reading from storage media or removable media,
• At least one communication interface for communication with a PC system,
• - Preferably, a display device.

The mobile transfer device is a small device that can be carried by a user. It can be used as an accessory to a workplace and in particular to a notebook. The mobile transfer device basically provides the same functionality as a (non-mobile) transfer device described above, but does not use its own interface on the mobile transfer device for user interaction, but rather a PC system (eg a workstation or notebook) to which she is connected. The mobile transfer device, like the transfer device already described above, consists of an execution environment and a security module according to the invention. In particular, the mobile transfer device is designed to carry out the transfer method according to the invention and its further developments.

The mobile transfer device preferably has a display device, preferably a small display, on which the device can display short messages / error messages.

The security module of the mobile transfer device preferably has a physical interaction mechanism as described above with respect to the security module. The physical interaction mechanism may be configured, for example, as a switch, knob, or lever and is preferably mounted protected on the mobile transfer device.

The security module of the mobile transfer device preferably has a physical status indicator as described above with respect to the security module. For example, a physical status indicator may be embodied as an optical display or signal lamp, and is preferably arranged on the mobile transfer device such that it can display a state or a function to a user. Preferably, the display is labeled accordingly.

In particular, the physical interaction mechanism and / or the physical status indicator also serve in the mobile transfer device to provide a direct, trusted path to the user, independent of the (possibly compromised, ie infected by malware) PC system (and possibly its screen / keyboard) is running.

Physically, the mobile transfer device is as small as possible. Particularly preferred is a size of the mobile transfer device, which corresponds approximately to that of a mobile phone, especially for use with a notebook. The mobile transfer device is a trusted import / export device that enables the secure import and export of data independently of an unsecured PC system.

The mobile transfer device has at least one interface for reading out storage media or removable data carriers, preferably located on one side of the device and designed, for example, as a socket for USB devices and memory cards. Here the user can insert memory cards from which data should be imported or exported to the data.

The mobile transfer device further includes a communication interface for communicating with a personal computer system. This is preferably located on another side of the device. This communication interface must be able to connect both storage media and communication interfaces. For example, a USB interface is preferred, but other types of interfaces can also be used.

The mobile transfer device preferably receives power via the communication interface to the PC system. Preferably, the mobile transfer device has no further connections.

The mobile transfer device is preferably adapted to present itself via communication interface as either two separate devices (a storage medium and a communication interface), or as a storage device allowing for special further commands. Preferably, the user on the PC system uses client software to communicate with the mobile transfer device. The client software may either be standardized software such as a web browser (if the mobile transfer device presents a network interface card as a communications interface) or client software developed specifically for this purpose.

The mobile transfer device is preferably suitable in principle for being operated in two ways. Either the PC user used the mobile transfer device as a mechanism to protect itself from threats from unknown files, or the PC user is protected third of such risks, ie "patronized". In the first case, the PC user also has full configuration control over the mobile transfer device. In the second case, he can use the mobile transfer device as part of the legitimate transfer processes, but make no configuration changes.

These different modes of operation are preferably mapped over two different roles. The role as transfer user and a second role as transfer administrator. Both roles use separate interaction mechanisms and authentication mechanisms. They can thus be perceived separately or simultaneously. In the first described application case, the PC owner has both roles and uses them as needed. In the second case, the transfer manager role is handled by a separate system or security manager who is not the user of the PC system. This will be particularly the case in organizations where there is centralized system administration.

In the first case, the use of the mobile transfer device per se is left to the user. Since he protects himself by their use, it is up to him to assess individual import / export situations with regard to their risk and to weigh up the necessity of using the mobile transfer device.

In the second case, the mobile transfer device restricts the communication that is possible with the PC system and thus patronizing the PC user. Here, it is additionally necessary that the PC system be administratively limited in its communication so that the PC user can not bypass or manipulate the mobile transfer device. The PC system may only communicate with the mobile transfer device via all possible import interfaces (eg all USB interfaces of the PC system). For this it is necessary that the mobile transfer device must authenticate itself to the PC system (this is done using the transfer device identity module of the mobile transfer device). Furthermore, it is necessary that a tamper-proof interface module (designed as software or hardware) that can not be changed by the user of the PC system requests and checks this authentication. This may, for example, be implemented as a limiting interface driver backed up by the operating system kernel.

In the "guardianship scenario", the mobile transfer device is effectively the representative of the policy-giving entity ("administrator": system administrator, security administrator, company policy) and decides which transfer processes are possible or permitted for the PC user. In the mobile transfer device, the administrator's specifications are stored in the form of the configuration and are kept up to date by the latter. Since no direct connection of the mobile transfer device to the administrator or a management system is necessary, the mobile transfer device can enforce the manager's defaults on the user "on the road".

Since the mobile transfer device preferably does not have its own power supply, a system start of the mobile transfer device takes place with the insertion of the mobile transfer device into the PC system. This is similar to starting a transfer program of the transfer method according to the invention on a transfer device according to the invention with a security module according to the invention.

Upon startup, the mobile transfer device is available through the communications interface and can be used by the PC system to transfer data. For this purpose, the PC user starts the client software. The client software signals the communication interface that a new transfer process should be started. Alternatively, the mobile transfer device can also perform this signaling when a new removable disk is inserted by the user in the interface for reading from storage media or removable media. The client software provides the same (limited) functions to the mobile transfer device via keyboard and mouse as the interaction interface of the (non-mobile) transfer device described above for communication with a user. All user actions are sent by the client software as commands to the mobile transfer device and the responses of the mobile transfer device are received by the client software and displayed to the user via the client software.

The mobile transfer device thus allows the use of a specially secured and encapsulated import / export device, which can be used as a notebook accessory by the PC user on the go because of its small physical size.

The mobile transfer device is furthermore preferably designed to perform an update of an executable transfer program code stored in the mobile transfer device or parts thereof as described above.

When performing an update using the mobile transfer device, updates are preferably sent as digitally signed software packets to the security module of the mobile transfer device and signed by the mobile transfer device. In addition to the digital signature, the software packages can also be completely encrypted. This ensures a trusted channel between the system administrator and the mobile transfer device. This is especially important if updates are to be made to several different mobile transfer devices and the corresponding software packages may contain sensitive data that should not be made accessible to the user of the PC system. Preferably, a user can neither communicate directly with the memory of the mobile transfer device (and access the internal data) nor view the software package during its transfer. An update is done via the PC system, either (semi-) automatically, z. B. supported by the client software, or manually. Similar to updating antivirus signatures, again, the client software may periodically check (preferably whenever the system is currently in a network connection to a central management component) for the presence of an updated version of the software package. If so, it will be downloaded and transferred to the mobile transfer device. Since the user of the PC system could in principle prevent this, the time-limited validity of software packages and one, for example optical, signaling via the physical status display or the setting of the operation by the mobile transfer device, in particular by the security module according to the invention, particularly important. Even if a malicious program has infected the PC system, it is not possible for it to install a wrong malicious software package on the mobile transfer device or pretend an update unnoticed because the mobile transfer device will display the current state via the physical status indicator and be able to set all functions if not updated too long.

Preferred embodiments of various aspects of the invention will be described by way of example with reference to the accompanying drawings. Show it:

1 FIG. 2 is a schematic representation of the stock of modules provided in a method according to the invention for providing an executable transfer program code. FIG.

2 3 is a schematic flow diagram of a part of steps of an embodiment of a method according to the invention for providing an executable transfer program code.

3 FIG. 1 shows a schematic representation of an embodiment of an embodiment of a transfer device according to the invention, FIG.

4 FIG. 3 is a schematic flow diagram of the execution steps of an embodiment of a transfer method according to the invention, FIG.

5 FIG. 2: a schematic representation of an embodiment of a security module according to the invention, FIG.

6 FIG. 3 is a schematic flowchart of the updating steps of an embodiment of a transfer method according to the invention and FIG

7 : a schematic representation of an embodiment of a mobile transfer device according to the invention.

1 shows a schematic representation of the supply of modules provided in a method according to the invention for providing an executable transfer program code 100 ,

Stock 100 various modules includes: at least one storage location module 120 wherein the storage location module is configured to allow access to a storage location, at least one functional module 110 wherein the function module is adapted to read data from a first storage location, to provide a security function on the data and to write the data to a second storage location, at least one workflow module 130 wherein the workflow module comprises at least one configuration parameter for controlling the storage location and / or function modules, preferably at least one identity module 140 , wherein the identity module is formed as stored data or as hardware, preferably at least one reference 160 to an update source, and preferably at least one secondary software module 150 ,

2 shows a schematic flow diagram of a part 300 the steps of an embodiment of a method according to the invention for providing an executable transfer program code.

• – Instanziieren 310 des mindestens einen Workflow-Moduls auf Basis der ausgewählten Konfigurationsparameter zu mindestens einer Workflow-Instanz,
• – Auswählen 320 von für die mindestens eine Workflow-Instanz erforderlichen Speicherort- und Funktions-Module,
• – ggf. Auswählen 330 von für die ausgewählten Speicherort- und Funktions-Module erforderlichen Sekundärsoftware-Module,
• – ggf. Auswählen 340 von für die ausgewählten Sekundärsoftware-Module erforderlichen weiteren Sekundärsoftware-Module,
• – Signieren 350 des ausführbaren Transferprogrammcodes,
• – Schreiben 360 des ausführbaren Transferprogrammcodes auf ein geschütztes Speichermedium,
• – Verschlüsseln 370 des ausführbaren Transferprogrammcodes.

The compilation 300 The executable transfer program code comprises in particular the steps:

• - instantiate 310 the at least one workflow module based on the selected configuration parameters for at least one workflow instance,
• - Choose 320 of storage and function modules required for the at least one workflow instance,
• - If necessary select 330 of secondary software modules required for the selected storage and function modules,
• - If necessary select 340 of additional secondary software modules required for the selected secondary software modules,
• - Sign 350 the executable transfer program code,
• - Write 360 the executable transfer program code on a protected storage medium,
• - Encrypt 370 the executable transfer program code.

3 shows a schematic representation of an embodiment of an embodiment of a transfer device according to the invention 400 ,

The transfer device 400 for the controlled transfer of data between domains as basic components 410 a processor 410a and a main memory 410b , a protected interface 420 for reading a protected storage medium, a transfer device identity module 430 comprising cryptographic material, a trust anchor 440 , at least one interface 450 for reading from storage media or removable media, at least one communication interface 460 for communicating with storage locations, and at least one interaction interface 470 for communication with a user.

4 shows a schematic flow diagram of the execution steps of an embodiment of a transfer method according to the invention.

• – Bereitstellen eines ausführbaren Transferprogrammcodes, vorzugsweise mittels eines Verfahrens nach dem vorhergehenden Anspruch,
• – Starten 510 eines Transferprogramms durch Ausführen des Transferprogrammcodes,
• – Prüfen 520, ob das gestartete Transferprogramm einem Referenzzustand entspricht,
• – Falls das das gestartete Transferprogramm nicht dem Referenzzustand entspricht:
• – Normalisieren 530 des Transferprogramms und Wiederholen der Prüfung,
• – Falls das gestartete Transferprogramm dem Referenzzustand entspricht:
• – Anbieten 540 einer Auswahl von Transfervorgängen,
• – Ausführen 560 eines ausgewählten Transfervorgangs,
• – Zurücksetzen 570 des Transferprogramms in den Referenzzustand.

A transfer procedure for the controlled transfer of data between domains comprises the steps:

• Providing an executable transfer program code, preferably by means of a method according to the preceding claim,
• - Start 510 a transfer program by executing the transfer program code,
• - Check 520 whether the started transfer program corresponds to a reference state,
• - If the transfer program started does not match the reference state:
• - Normalize 530 the transfer program and retake the exam,
• - If the transfer program started corresponds to the reference state:
• - To offer 540 a selection of transfer transactions,
• - To run 560 a selected transfer transaction,
• - Reset to default 570 of the transfer program in the reference state.

5 shows a schematic representation of an embodiment of a security module according to the invention.

The security module 600 providing and updating protected memory contents includes a non-volatile payload memory area 610 , wherein the useful memory area a first 611 and a second 612 Part area has a mark 620 , which indicates which of the two subregions carries a marker as "active", a crypto-processor 630 for performing cryptographic operations, a slotted memory area 640 for storing at least one certificate, a real-time clock 650 , preferably a physical interaction mechanism 660 , preferably a physical status indicator 670 and an interface 680 for reading out the safety module by a system.

Furthermore, the security module 600 characterized in that the Nutzspeicherbereich 610 is formed such that at the interface for reading the security module by a system only that of the two sub-areas 611 . 612 is readable, which carries a mark as "active".

Preferably, the security module 600 in combination with a transfer device 400 used, preferably the interface 680 for reading out the safety module by a system of the safety module 600 with the protected interface 420 for reading a protected storage medium of the transfer device 400 interacts.

6 shows a schematic flow diagram of the update steps of an embodiment of a transfer method according to the invention.

A transfer method for controlled transfer of data between domains preferably further comprises the step of updating the provided executable transfer program code, the updating comprising the steps of: triggering 720 updating, preparing 730 updating, checking 740 the received data, and exit 750 the update.

It is particularly preferred that the abutment 720 The upgrade includes one or more of the following: Request 721 an update by a user, request 722 an update after expiration of a predetermined time since an event, and / or checking 723a the availability of an updated version of the executable transfer program code and request 723b an update if the check shows that an updated version is available.

Furthermore, it is particularly preferred that the preparation 730 The update includes one or more of the following: Signaling 731 readiness to receive an updated version of the executable transfer program code 732 an updated version of the executable transfer program code, Save 733 the updated version of the executable transfer program code, signaling 734 the completion of the reception, termination 735 of reception.

Furthermore, it is particularly preferred that the testing 740 the updated version of the executable transfer program code comprises one or more of the following steps: verify 741 a digital signature of the updated version of the executable transfer program code, Check 742 a certificate of the updated version of the executable transfer program code, Check 744 whether the time stamp and / or a version number of the updated version of the executable transfer program code is newer than the time stamp and / or a version number of a previously used version of the executable transfer program code, discard 743 the updated version of the executable transfer program code for a negative result of at least one of the checks of the preceding steps, Accept 745 the updated version of the executable transfer program code for a positive result of all checks of the previous steps.

Furthermore, it is particularly preferred that quitting 750 The update includes one or more of the following: Signaling 752 a result of the update, deploy 753 the updated version of the executable transfer program code.

7 shows a schematic representation of an embodiment of a mobile transfer device according to the invention 800 ,

The mobile transfer device 800 for the controlled transfer of data between domains, comprises as basic components 810 a processor 810a and a main memory 810b , a security module 600 , a transfer device identity module 830 comprising cryptographic material, a trust anchor 840 , at least one interface 850 for reading from storage media or removable media, at least one communication interface 860 for communication with storage locations, and a display device 870 ,

Claims (9)

A method for providing an executable transfer program code for a transfer program for the controlled transfer of data between domains, comprising the steps of: providing a supply of different modules, wherein a module comprises executable program code of a part of a transfer program, the supply of different modules comprising: at least one Location module ( 120 ), wherein the storage location module is designed to allow access to a storage location, - at least one functional module ( 110 ), wherein the function module is designed to read data from a first storage location, to provide a security function on the data and to write the data to a second storage location, - at least one workflow module ( 130 ), wherein the workflow module comprises at least one configuration parameter for controlling the storage location and / or function modules, preferably at least one identity module ( 140 ), wherein the identity module is designed as stored data or as hardware, preferably at least one reference ( 160 ) to an updating source, preferably at least one secondary software module ( 150 ), - offering a selection of configuration parameters, - compiling ( 300 ) of the executable transfer program code by - instantiating ( 310 ) of the at least one workflow module based on the selected configuration parameters for at least one workflow instance, 320 ) of storage location and function modules required for the at least one workflow instance, - if necessary, select ( 330 ) of secondary software modules required for the selected storage location and function modules, - if necessary, select ( 340 ) of additional secondary software modules required for the selected secondary software modules, - signing ( 350 ) of the executable transfer program code, - write ( 360 ) of the executable transfer program code to a protected storage medium, - encrypting ( 370 ) of the executable transfer program code. Transfer method for the controlled transfer of data between domains, comprising the steps of: Providing an executable transfer program code, preferably by means of a method according to the preceding claim, 510 ) of a transfer program by executing the transfer program code, - checking ( 520 ), if the started transfer program corresponds to a reference state, - If the transfer program started does not correspond to the reference state: - Normalize ( 530 ) of the transfer program and repeat the test, - If the transfer program started corresponds to the reference state: - Offer ( 540 ) of a selection of transfer transactions, - Execute ( 560 ) of a selected transfer, - Reset ( 570 ) of the transfer program in the reference state. A transfer method according to the preceding claim, characterized by the step of updating the provided executable transfer program code, the updating comprising the steps of: - initiating ( 720 ) updating, - preparing ( 730 ) of updating, - checking ( 740 ) of the received data, - Quit ( 750 ) of the update. Transfer method according to the preceding claim, characterized in that - the initiation ( 720 ) the update comprises one or more of the following steps: - request ( 721 ) an update by a user, - request ( 722 ) an update after a predetermined time has elapsed since an event, - checking ( 723a ) the availability of an updated version of the executable transfer program code and request ( 723b ) an update if the check indicates that an updated version is available, - and / or preparing ( 730 ) the update comprises one or more of the following steps: - signaling ( 731 ) the readiness to receive an updated version of the executable transfer program code, - receive ( 732 ) an updated version of the executable transfer program code, - Save ( 733 ) of the updated version of the executable transfer program code, signaling ( 734 ) the completion of the reception, - termination ( 735 ) of reception, - and / or testing ( 740 ) of the updated version of the executable transfer program code comprises one or more of the following steps: - verifying ( 741 ) a digital signature of the updated version of the executable transfer program code, - check ( 742 ) a certificate of the updated version of the executable transfer program code, - check ( 744 ), whether the time stamp and / or a version number of the updated version of the executable transfer program code is newer than the time stamp and / or a version number of a previously used version of the executable transfer program code, - discard ( 743 ) of the updated version of the executable transfer program code in the event of a negative result of at least one of the checks of the preceding steps, - accepting ( 745 ) of the updated version of the executable transfer program code if the result of all checks of the preceding steps, - and / or the termination ( 750 ) the update comprises one or more of the following steps: - signaling ( 751 ) of a result of the update, - providing ( 752 ) of the updated version of the executable transfer program code. Transfer device ( 400 ) for the controlled transfer of data between domains, comprising - a processor ( 410a ) and a main memory ( 410b ), - a protected interface ( 420 ) for reading out a protected storage medium, - a transfer device identity module ( 430 ) comprising cryptographic material, - an anchor of trust ( 440 ), - at least one interface ( 450 ) for reading from storage media or removable media, - at least one communication interface ( 460 ) for communication with storage locations, - at least one interaction interface ( 470 ) for communication with a user. Security module ( 600 for providing and updating protected memory contents, comprising - a non-volatile payload memory area ( 610 ), wherein the useful memory area a first ( 611 ) and a second ( 612 ) Subarea, - a marker ( 620 ), which indicates which of the two subareas carries a marking as "active", - a crypto-processor ( 630 ) for performing cryptographic operations, - a protected memory area ( 640 ) for storing at least one certificate, - a real-time clock ( 650 ), Preferably a physical interaction mechanism ( 660 ), Preferably a physical status indicator ( 670 ) An interface ( 680 ) for reading out the safety module by a system. Security module ( 600 ) according to the preceding claim, characterized in that the useful memory area ( 610 ) is designed such that at the interface for reading the security module by a system only that of the two sub-areas ( 611 . 612 ) is readable, which carries a mark as "active". Transfer device ( 400 ) according to claim 5, characterized in that the transfer device is a security module ( 600 ) according to claim 6 or 7. Mobile transfer device ( 800 ) for the controlled transfer of data between domains, comprising - a processor ( 810a ) and a main memory ( 810b ), - a security module ( 600 ) according to claim 6 - a transfer device identity module ( 830 ) comprising cryptographic material, - an anchor of trust ( 840 ), - at least one interface ( 850 ) for reading from storage media or removable media, - at least one communication interface ( 860 ) for communication with storage locations, preferably a display device ( 870 ).

Images