PROCEDURE FOR VALIDATION OF A DIGITAL CERTIFICATE

Description

[0001] The invention relates to a method for validating a digital certificate by means of a validation device which checks the certificate of a communication partner on behalf of a first device, as well as a validation device and a status collection device for carrying out the method.

[0002] Devices, for example in an automation system, communicate with other devices or control platforms via a data network. Such communicating devices are often referred to as Internet of Things (IoT) devices. IoT devices increasingly use digital certificates to authenticate themselves to other communication partners or to services provided, for example, on application servers. Digital certificates, such as those conforming to the ITU-T standard X.509, are issued by a key infrastructure issuing authority and their validity is confirmed by a signature using the issuing authority's private key.

[0003] To validate such a certificate, dhSeveral steps are required to verify the validity of a certificate. These include checking the certificate's digital signature, its validity period, its intended use, and the identity of the certificate holder. Furthermore, the certificate must be checked against a revocation list. The certificate path must also be verified, meaning the certificates along the certificate chain must be checked back to a root certificate. During validation, the signatures of all certificates in the certificate chain, as well as specific parameters within the certificate itself, are examined.

[0004] These various steps are memory- and computationally intensive, placing a particular burden on IoT devices, which are often simply structured and have limited processing and storage capacity. This delays the execution of other processes within the device. Furthermore, the verification process is performed on different IoT devices in the same way, allowing the results to be shared with others so that the verification itself can be performed on only one component.

[0005] CH713421A2 describes a method for verifying a certificate by verifying a signature of the certificate in response to a received request for certificate verification, by comparing authentication information contained in a certificate issuance request transaction with authentication information contained in the certificate, and by determining whether the certificate has been revoked.

[0006] US2005 / 273610A1 discloses an information processing device for verifying the validity of a communication partner's certificate. For this purpose, information to identify the information processing device and the result of the verification are transmitted externally.

[0007] It is common practice to delegate the verification of one or more certificates to a validation service on a server located away from the device. This service then provides the device with a single response message containing the complete certificate validation. Standardized procedures and, in particular, signaling protocols such as the Online Certificate Status Protocol (OCSP) or the Server-Based Certificate Validation Protocol (SCVP) are used for this purpose. These protocols allow the status of a digital certificate to be queried from the validation service, and the certificate path construction, including validation, to be carried out. In larger plant networks that are subdivided into several subnetworks, one such server is often responsible for the devices in each subnetwork.

[0008] It is also possible to store a certificate validation result for a specific period on such a server. If a device requests the validation of a certificate for which a validation result already exists on the server, and the device allows the use of a stored validation result, the server no longer explicitly checks the certificate or the certificate path, but instead returns the stored certificate result to the requesting device.

[0009] However, such cached certificate validation results are only stored for a limited time and only on the requested server.

[0010] While using such a server for certificate validation reduces the computing and storage capacity of individual IoT devices, it results in a significant response time until the validation result is available on the device, as well as increased computing overhead on the server. If a large number of IoT devices in a system are interconnected or connected to a service or application server, the same certificates are often validated by different servers.

[0011] The object of the present invention is therefore to provide the result of a validation of certificates or certificate chains for the entire plant network in a time-optimized manner and with the lowest possible computational effort.

[0012] The problem is solved by the measures described in the independent claims. Advantageous embodiments of the invention are described in the dependent claims.

[0013] According to a first aspect, the invention relates to a method for validating a digital certificate by means of a validation device which verifies the certificate of a communication partner on behalf of a first device, comprising the method steps: Requesting a validation of the communication partner's certificate by the first device at a first validation device, querying validation information by the first validation device at a status collection device, checking in the first validation device whether validation information has been received from the collection device, and sending the validation information from the first validation device to the first device, wherein The validation information of the certificate is only determined in the first testing device if the test result is negative.

[0014] Communication partners of the device include, for example, other devices located in the same or different subnetwork areas of a plant network. Communication partners also include devices, servers, or other equipment located outside the plant network and connected to the device via a communication network, such as the internet. Validation refers to the verification of a certificate's validity, while validation information is the result of that validation. The requested certificate validation can encompass several aspects, such as verifying the certificate's integrity, constructing and validating the certificate chain, and / or checking various certificate parameters. The validation information can therefore contain multiple test results.

[0015] By querying the validation information at the status collection device, the validation information stored there can be determined without requiring validation within the validation device itself, and thus sent to the first device in a timely manner. The first device is also barely burdened by the outsourced certificate verification. Therefore, this method is particularly suitable for IoT devices. Only in the event of a negative test result, i.e., if the status collection device does not provide any validation information, is the validation information determined in the first validation device, thus ensuring that the first device receives the validation information.

[0016] In an advantageous embodiment, in the event of a negative test result, the validation information determined in the first validation device is additionally forwarded to the status collection device.

[0017] This ensures automatic initial population and updating of the status collection device with validation information. No additional process is required to provide validation information to the status collection device. This is initiated and carried out automatically by the first testing device after each query for validation information with a negative result, i.e., without the status collection device returning the validation information.

[0018] In an advantageous embodiment, the validation information is stored in the form of a block of a blockchain in a blockchain storage device.

[0019] Storing the validation information as a block on a blockchain makes it more difficult to alter or manipulate the validation information and ensures its integrity. The blockchain storage device can be structured as a distributed storage system, with each block containing an instance of the blockchain. This allows the validation information to be distributed across multiple storage devices without further precautions and thus easily made available to an initial validation device.

[0020] In an advantageous embodiment, the validation information is stored as an element of a database in the status collection device.

[0021] Storing the validation information as an element of a database offers a simple and fast deployment option.

[0022] In an advantageous embodiment, the validation information is sent from the first validation unit to the first device without cryptographic protection.

[0023] This enables a particularly short response time between the first validation device and the first device. In many cases, the first validation device and the first device are located in a protected area, making the transmission link difficult to access and therefore difficult to manipulate, so that even without cryptographic protection, manipulation is unlikely.

[0024] In an advantageous embodiment, the validation information is cryptographically protected by the first validation device, in particular digitally signed, forwarded to the status collection device and stored.

[0025] This reduces the risk of manipulation of the validation information during transport to the status collection device.

[0026] In an advantageous embodiment, the validation information is cryptographically protected, in particular digitally signed, by the first validation device, forwarded to the status collection device and stored there.

[0027] Cryptographic protection of the validation information sent from the first validation device to the status collection device significantly reduces the risk of manipulation. Preferably, the validation information is signed with the private key of the first validation device. The validation information is thus also stored cryptographically protected in the status collection device. This allows the integrity of the validation information stored in the status collection device to be verified, making manipulation of the validation information within the status collection device more difficult.

[0028] In an advantageous embodiment, the validation information cryptographically protected by the first verification unit is transmitted from the status collection device to a second validation device in response to a request and is only sent to the second device after successful verification of the cryptographic protection in the second validation device.

[0029] This has the advantage that the transmission of validation information from the status collection device to the second validation device is very difficult for an unauthorized third party to read and manipulate. Furthermore, only a trust relationship, or the respective public key of the first validation devices contained in an automation network, needs to be known in each second validation device.

[0030] A device or validation device is designated as a first device or first validation device if the requested validation information is determined within the validation device itself and is not provided by the status collection device. A device or validation device is designated as a second device or second validation device if the requested validation information is not provided to the validation device by the status collection device. Therefore, each validation device or device can be both a first and a second validation device.

[0031] In an advantageous embodiment, the second validation device sends the validation information to the second device without cryptographic protection.

[0032] The second validation device sends validation information to the second device, for example, without a digital signature. This has the advantage that the validation information is forwarded without the delay that would occur due to verification of the validation information within the second validation device, thus shortening and optimizing the response time for answering the request for the validation information. This is particularly advantageous when the second validation device and the second device are located in an access-controlled or non-publicly accessible environment.

[0033] In an advantageous embodiment, the second validation device sends the validation information to the second device in a cryptographically protected manner.

[0034] This has the advantage that this last transmission section between the second validation device and the second device is also transmitted before manipulation and reading.

[0035] The validation information can either be cryptographically protected by the first validation device. This means that after verifying, for example, the digital signature of the first device against the validation information, this signature is then forwarded along with the validation information to the second device. In this case, the second device must have a trust relationship with each of the first validation devices, meaning it must know, for example, the public key of each of these first validation devices. However, no new signature needs to be calculated, thus reducing processing time and the overall response time to the request. Alternatively, the validation information can also be cryptographically protected by the second validation device.In this case, for example, a digital signature is created using the positively verified validation information and the private key of the second validation device, and then sent to the second device. In this case, the second device only needs to have a trust relationship with the second validation device, for example, by knowing the public key of the second validation device.

[0036] In an advantageous embodiment, the validation information cryptographically protected by the first verification unit is checked in the status collection device, and if the check is successful, the cryptographic protection by the first verification unit is replaced by cryptographic protection by the status collection device and stored in the status collection device.

[0037] This has the advantage that the second validation device, or the second device in general, only needs to have a trust relationship with the status collection device. This means that the second validation device and the second device only need to know, for example, the public key of the status collection device. Therefore, updating this single key is also simple and requires minimal transmission and administrative effort.

[0038] In an advantageous embodiment, the validation information is only transmitted from the status collection device to the validation device if the validation information is stored in the status collection device for a shorter period of time than a predetermined duration.

[0039] The specified time period can, for example, be transmitted from the first validation device to the status collection device along with the validation information and correspond, for instance, to the time until the earliest next update of a certificate revocation list or to a specific duration. Alternatively, the specified time period can be predefined in the status collection device or calculated by the status collection device based on the time the validation information is received. This ensures that the validation information reflects the current status at the time of retrieval.

[0040] In an advantageous embodiment, the process steps are executed by means of protocol messages in accordance with a standardized certificate validation protocol, in particular a server-based certificate validation protocol, or SCVP for short.

[0041] Existing, especially standardized, certificate validation protocols can therefore be used as the basis for the described procedure. Only a few extensions are required, such as a query message that a first validation device, configured as an SCVP server, sends to the status collection device. Existing identifiers in the certificate validation protocol, such as a flag that allows the use of stored validation information, can be reused for the described procedure. Thus, the effort required to implement the procedure remains manageable.

[0042] A second aspect of the invention relates to a validation device for validating a digital certificate, which verifies the certificate of a communication partner on behalf of at least one first device, comprising at least one processor configured to receive a request for validation of the communication partner's certificate from the first device, to query a status collection device for validation information, to check whether validation information has been received from the status collection device and to send the validation information to the first device, and only in the case of a negative test result, to determine the validation information of the certificate itself and to forward the determined validation information to the status collection device.

[0043] The validation device can thus query validation information previously stored in the status collector, thereby generating a low processor load for retrieving the validation information. If no validation information is retrieved from the status collector in response to the request, the validation information is generated and, in addition to being sent to the first device, forwarded to the status collector. A validation device configured in this way not only has a reduced response time but also automatically populates and updates the status collector.

[0044] A third aspect of the invention relates to a status collection device comprising at least one processor, characterized in that the processor is configured to receive a request for validation information from the first validation device, to transmit the validation information to the first validation device and / or to receive and store the validation information from the first validation device, and sends a response message without validation information to a request to the first validation device (15) if no validation result is determined, and the validation information is determined locally in the first validation device (15) since no validation information is contained when a received message is checked for the validation information in the first validation device (15).

[0045] Such a status collection device stores validation information from a multitude of devices, which is transmitted to a first or second device upon request. Such a centralized status collection device can be protected and updated more easily than a distributed system.

[0046] A fourth aspect of the invention relates to a computer program product comprising a non-volatile, computer-readable medium that can be directly loaded into a memory of a digital computer, comprising program code segments suitable for performing the steps of the method according to one of the described method steps.

[0047] Unless otherwise specified in the following description, the terms "request," "request," "check," "send," and the like preferably refer to actions and / or processes and / or processing steps that modify and / or generate data and / or convert data into other data, wherein the data may be represented or exist as physical quantities, for example, as electrical signals. In particular, the terms "device" or "computer" should be interpreted as broadly as possible to encompass all electronic devices with data processing capabilities. Devices may include, in particular, devices in an automation system that can process data using a computer, processors, and other electronic devices for data processing.

[0048] In the context of the invention, a processor can be understood to mean, for example, a main processor, a microprocessor, or a microcontroller, such as an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc. A processor can also comprise several individual processors of various types. Each "unit" can be implemented in hardware and / or software. In a hardware implementation, the respective unit can be designed as a device or as part of a device, e.g., as a computer, a microprocessor, or a control computer. In a software implementation, the respective unit can be designed as a computer program product, a function, a routine, part of program code, or an executing object.

[0049] A computer program product, such as a computer program tool, can be provided or delivered, for example, as a storage medium such as a memory card, USB stick, CD-ROM, DVD, or as a downloadable file from a server in a network.

[0050] Exemplary embodiments of the method according to the invention, the validation device, and the status collection device are shown in the drawings and are explained in more detail below. The drawings show: Fig. 1 shows an application scenario with embodiments of the first and second validation devices and the status collection device according to the invention, in which the method according to the invention is carried out in block representation; Fig. 2 shows a first embodiment of the method according to the invention as a flowchart; Fig. 3 shows a second embodiment of the method according to the invention as a message exchange diagram; Fig. 4 shows a first embodiment of a validation device according to the invention in block representation; and Fig. 5 shows a first embodiment of a status collection device according to the invention in block representation.

[0051] Corresponding parts are marked with the same reference symbol in all figures.

[0052] Figure 1Figure 1 shows a communication network, for example, of an automation system, with two network zones 10 and 20, representing, for example, two different production areas. Devices 11, 12, 13, and 14 are located in the first network zone, and devices 21, 22, 23, and 24 are located in the second network zone 20. The devices can be, for example, field devices or control units. A validation device 15 and 25 are located in each of the first and second network zones. These devices perform certificate validation locally in their respective network zones, acting as a proxy for device 11, ..., 14, and the second validation device 25 performs it for devices 21, ..., 24. The communication partner whose certificate is requested for validation can be, in addition to devices 11, ..., 14, 21, ..., 24, an external communication partner 34, such as an administration terminal or an application server, which is connected to the first and second network zones via a public network.

[0053] When using a known certificate validation protocol, such as the SCVP protocol, a device, for example, the first device 11, requests validation of one or more certificates from the first validation device 15. Additionally, the first device 11 can specify several sub-checks, such as constructing and verifying the certificate chain, and / or a verification policy. The verification policy specifies which sub-checks are to be performed on the certificate. This includes, for example, verifying the key's usability, the root certificates to be used, and so on. The first device can also describe in the request the information it expects as a result. This includes, for example, checking the revocation status of all certificates in a certificate chain or verifying the entire certificate chain as a data element.The first device 11 can also specify whether the response should be transmitted securely from the first validation device 15. Such cryptographic protection can be implemented, for example, by a digital signature using a private key of the first validation device. Likewise, the first device 11 can indicate in the request whether it accepts a validation result stored in the first validation device, which is hereinafter referred to as validation information.

[0054] According to the invention, the result of the certificate validation, i.e., the validation information, is now provided by a status collection device 30. This validation information provided on the status collection device 30 can be used to reduce the response time between the sending of the query by the first device 11 and the response and provision of the requested validation information on the first device 11 for the same certificate, since it is no longer necessary to perform all validations separately in the first validation device 15. The validation information can be provided in a public directory in a status database 32, which is administered and controlled by a control device 31. Alternatively, the validation information can be stored and provided by a blockchain storage device 33.In the first case, the validation information is stored as an element of database 32 in the state collection device. In the second alternative, the validation information is stored in the form of a block of a blockchain in the blockchain storage device 33, which can also be designed as a distributed storage device.

[0055] Based on Figure 2 The individual process steps will now be described in detail. In an initial state, see S0, the first device, for example device 11, wants to Figure 1, verify a certificate of a communication partner. The communication partner can be any device in the first or second network zone 10, 20, or an external communication partner 34. In the first process step S1, the first device 11 requests certificate validation from a first validation device 15. To do this, the first device 11 sends, for example, a request message containing the certificate to be verified to the first validation device 15. Such a request or request message can also include the validation of multiple certificates.

[0056] Subsequently, in step S2, the first validation device 15 requests validation information from a status collection device 30. The status collection device 30 determines validation information based on the information contained in a request message, i.e., a specification of the certificate and optionally further requested partial checks. If one or more validation pieces or partial validation pieces are available in the status collection device 30, they are transmitted, for example, in a response message to the query sent to the first validation device 15. If no validation information can be determined in the status collection device 30, a response message is preferably also sent to the first validation device 15, but this message does not contain any validation information.

[0057] In process step S3, the first validation device 15 checks whether validation information has been received from the status collection device 30. Subsequently, in process step S4, the validation information is sent from the first validation device 15 to the first device, thus answering and completing the certificate validation request (see S7). If the check (see S3) yields a negative result, the certificate validation information is determined in the first validation device 15 (see S5) and sent to the first device (see S4).

[0058] This ensures that validation information is provided to the first device 11 in any case.

[0059] If the validation information was determined in the first validation device 15, see S5, then in a further procedure step S6 the validation information is forwarded from the first validation device 15 to the status collection device 30 and the procedure is terminated, see S8.

[0060] In Figure 3 The method according to the invention is described using a specific example in which the first device 11 from the first network zone 10 sends a certificate request to the first validation device 15, for which no validation information is yet available in the status collection device 30. Subsequently, a second device 21, which is located in the second network zone 20, requests the same certificate from the second validation device 25, which is also located in the second network zone 20.

[0061] Starting point 100, the first device 11 again has a need to validate a certificate from a communication partner. For this purpose, the first device 11 sends a request message containing the corresponding certificate of the communication partner and, optionally, further information on the desired sub-checks to the first validation device 15 (see 101). The first validation device 15 sends, for example, a request message to the status collection device 30, requesting the return of validation information for this certificate (see 102). The status collection device 30 then checks whether such a validation result is available.

[0062] In this case, no validation result can be determined, so the status collection unit 30 sends a response message without validation information to the request to the first validation device 15 (see 103). The first validation device 15 then checks the received message for validation information and, since no validation information is contained, verifies the certificate locally within the first validation device 15 to determine the validation information (see 104). The first validation device 15 then sends the validation information in an unsecured response message to the first device 11 and also in a cryptographically protected message to the status collection unit 30 (see 105). The validation information is stored in the status storage device (see 106) and can now be made available to other devices.

[0063] The validation information can be cryptographically protected, in particular digitally signed with a private key of the first validation device 15, and stored in the status collection device 30. Alternatively, the cryptographic protection of the validation information by the first validation device 15 is replaced by digital protection by the status collection device 30. For example, the digital signature of the validation information by the first validation device 15 can be replaced by a digital signature of the status collection device 30.

[0064] Furthermore, a second device 21 also requires validation of the same certificate (see 110). Following the procedure already described, the second device 21 requests certificate validation from the second validation device 25 (see 111). The second validation device 25 requests the certificate validation information from the status collection device 30 (see 112). Since the validation information is now available in the status collection device 30, it is retrieved by the status collection device 30 (see 113) and transmitted in a response message to the second validation device 25 (see 114). The second validation device 25 then verifies the cryptographic protection of the validation information (see 115) and subsequently transmits the validation information to the second device 21 (see 116).

[0065] The validation information can be sent to the second device 21 either unprotected or alternatively with the cryptographic protection of the received validation information or message. Alternatively, the second validation device 25 can send the validation information itself to the second device 21 with cryptographic protection, for example, a signature using the private key of the second validation device 25. Accordingly, the public key of the component that cryptographically protected the validation information must be present in the receiving units, for example, the status collection device 30, the second validation device 25, or the second device 25. Depending on the trustworthiness of the individual components, a more or less conspicuous key management system is necessary.

[0066] In Figure 4A validation device 40 is shown. It comprises a first input / output unit 41, which is configured to receive a request for validation of the communication partner's certificate from the first device and to send the determined validation information to the first device. The validation device 40 further comprises a second input / output unit 42, which is configured to query validation information from a status collection device and to forward validation information determined in the validation device 40 itself to the status collection device. The validation device 40 further comprises a verification unit 43 and a validation unit 44. The verification unit 43 checks the response to the request message from the status collection device for contained validation information.The validation unit 44 validates the certificate itself, thus performing certificate validation. These units are implemented by one or more processors or electronic circuits.

[0067] Figure 5Figure 50 shows a status collection device. It comprises a control unit 51, an input / output unit 54, and a database 52, as well as, alternatively or additionally, a blockchain storage device 53. The input / output unit 54 is configured to receive a request message from a validation device and send a response message back to the validation device. The control unit 51 is configured to query the requested validation information from the database 52 or the blockchain storage device 53 and to input the received validation information into the database 52 or the blockchain storage device 53. The control unit 51 is further configured to verify the cryptographic protection of the validation information.The control unit 51 can also be designed to cryptographically protect validation information itself, for example by signing it with its own private key.

[0068] The proposed method for distributing validation information from the validation device to a central status collection device reduces the response time of the validation device to the requesting device, as it requires less processing time for validation, particularly of long certificate chains. The faster response time of the validation device to the requesting device thus also reduces the response time of the requesting device.

[0069] All described and / or illustrated features can be advantageously combined within the scope of the invention. The invention is not limited to the described embodiments. The invention is disclosed by the scope of the appended claims.

Claims

1. Method for the validation of a digital certificate, wherein a validation apparatus (15, 25) checks the certificate of a communication partner on behalf of a first device (11,...,14), comprising the method steps of: - the first device (11,...,14) requesting (S1) validation of the certificate of the communication partner at a first validation apparatus (15), - the first validation apparatus (15) querying (S2) validation information at a status collection apparatus (30), - checking (S3), in the first validation apparatus (15), whether validation information has been received from the status collection apparatus (30), and - transmitting (S4) the validation information from the first validation apparatus (15) to the first device (11), wherein, only in the event of a negative inspection result, the validation information of the certificate is determined (S5) in the first validation apparatus (15).

2. Method according to Claim 1, wherein, in the event of a negative inspection result, the validation information determined in the first validation apparatus (15) is additionally forwarded (S5) to the status collection apparatus (30).

3. Method according to either of the preceding claims, wherein the validation information is stored in the form of a block of a blockchain in a blockchain storage apparatus (33).

4. Method according to Claim 1 or 2, wherein the validation information is stored in the status collection apparatus (30) as an element of a database (32).

5. Method according to one of the preceding claims, wherein the validation information is transmitted from the first validation unit (15) to the first device (11) without cryptographic protection.

6. Method according to one of the preceding claims, wherein the validation information is cryptographically protected, in particular digitally signed, by the first validation apparatus (15), forwarded to the status collection apparatus (30) and stored in the status collection apparatus (30).

7. Method according to Claim 6, wherein the validation information cryptographically protected by the first validation apparatus (15) is transmitted from the status collection apparatus (30) to a second validation apparatus (25) in response to a request and transmitted to the second device (21) only after a successful check of the cryptographic protection in the second validation apparatus (25).

8. Method according to Claim 7, wherein the second validation apparatus (25) transmits the validation information to the second device (21) without cryptographic protection.

9. Method according to Claim 7, wherein the second validation apparatus (25) transmits the validation information to the second device (21) with cryptographic protection (15).

10. Method according to Claim 6, wherein the validation information cryptographically protected by way of the first checking unit (15) is checked in the status collection apparatus (30) and, in the event of a positive inspection result, the cryptographic protection by way of the first checking unit (15) is replaced with cryptographic protection by way of the status collection apparatus (30) and is stored in the status collection apparatus (30).

11. Method according to one of the preceding claims, wherein the validation information is transmitted from the status collection apparatus (30) to the validation apparatus (15) only when the validation information is stored in the status collection apparatus (30) for less than a predefined period.

12. Method according to one of the preceding claims, wherein the method steps are implemented by way of protocol messages in accordance with a standardized certificate validation protocol, in particular a Server-based Certificate Validation Protocol SCVP.

13. Validation apparatus for validating a digital certificate, wherein the validation apparatus checks the certificate of a communication partner on behalf of at least one first device (11,...,14), comprising at least one processor that is designed: - to receive a request (S1) to validate the certificate of the communication partner from the first device (11,...,14), - to query (S2) validation information at a status collection apparatus (30), - to check (S3) whether validation information has been received from the status collection apparatus (30), and - to transmit (S6) the validation information to the first device (11), and, only in the event of a negative inspection result, - to determine (S4) the validation information of the certificate itself, and - to forward (S5) the determined validation information to the status collection apparatus (30).

14. Status collection apparatus comprising at least one processor, wherein said processor is designed: - to receive a request message for validation information by a first validation apparatus (15), - to transmit the validation information to the first validation apparatus (15), and / or to receive the validation information from the first validation apparatus (15) and store it, and - to transmit a response message without validation information to a request to the first validation apparatus (15) if no validation result is determined, and the validation information is determined locally in the first validation apparatus (15), since no validation information is present when a received message is checked for the validation information in the first validation apparatus (15).

15. Computer program product comprising a non-volatile computer-readable medium that is able to be loaded directly into a memory of a digital computer, comprising program code parts that are suitable for performing the steps of the method according to one of Claims 1 to 12.