Method for configuring and / or updating software of target components of a safety-critical system using a central authentication unit, and safety-critical system with an authentication unit - Patents.com
A central authentication unit manages state transitions and version checks to automate secure updates in safety-critical systems, addressing the challenge of maintaining SIL4 safety levels during software updates.
Patent Information
- Application Number
- JP2025533389
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-12-09
- Filing Date
- 2023-12-08
- Publication Date
- 2025-12-11
AI Technical Summary
Existing methods for updating software in safety-critical systems, such as railway signaling equipment, do not allow for automatic state transitions of persistently certifiable target components while maintaining the required safety level SIL4, necessitating manual intervention and individual updates.
A method involving a central authentication unit that manages state transitions and version checks of persistently authenticated target components, ensuring secure and automated updates by transitioning components to a maintenance state, performing integrity checks, and reverting to operational state only when all components are synchronized.
Enables secure, automated, and scalable software updates in safety-critical systems, maintaining high safety levels by minimizing human intervention and ensuring all components are updated consistently.
Smart Images
Figure 2025540310000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to a method for configuring and / or updating software of target components of a safety-critical system from a starting system configuration to a target system configuration. The safety-critical system comprises a maintenance management component, a central authentication unit, and at least one persistently authenticated target component. The starting system configuration includes a first combination of target components, and the target system configuration includes a second combination of target components. The present invention also relates to a safety-critical system comprising a maintenance management component and at least one persistently authenticated target component that does not require a new authentication for a restart. [Background technology]
[0002] The software of system components, e.g. signaling devices in railway signaling equipment, needs to be installed or updated for various reasons (e.g. bug fixes, security patches, new software versions, configuration changes, etc.). System components may be physically distributed. For this reason, updates are advantageously performed through remote update functions, which allow updating distributed system components via a network from a central site. A system configuration contains, in particular, information about included, persistently attestable target components and their version requirements. Version requirements may change within a system configuration, i.e., inter alia, depending on the configuration of system components (combination of target components) and / or for individual target components. In the following, system components that are part of a system configuration (start and / or target system configuration) and therefore participate in the update are referred to as target components.
[0003] Non-Patent Document 1 discloses a method for modular testing of distributed components in safety-related systems. In particular, the method known in Non-Patent Document 1 allows field elements (e.g., points, axle counters, signals) to request certification from a signal center. Checksums are then exchanged between the associated applications via the SCI interface to verify data integrity. The method known in Non-Patent Document 1, which is performed during the operational phase, only describes the format of SCI messages and the presence of checksums. It does not specify how the checksums are generated, nor whether and how they map to configuration data, operating systems, or application software. This method is only suitable for updating the software of "connection-dependently certifiable target components," i.e., target components that must request a new certification from a higher-level target component whenever they are restarted. The method known in Non-Patent Document 1 does not allow for updating persistently certifiable target components while maintaining the safety level SIL4 (CENELEC SIL4) required for safety-critical systems. Rather, each target component that is capable of persistent authentication must be individually updated and checked by a maintainer. The specification only contains configuration data for each controlled target component; therefore, adjustments are required to check other target components. [Prior art documents] [Non-patent literature]
[0004] [Non-Patent Document 1] EULYNX Baseline Set3 Release6(https: / / eulynx.eu / index.php / documents / published-documents / open-availability / baseline-set-3 / 261-20201002-eulynx-baseline-set-3-cover-document-6a / file) Summary of the Invention [Problem to be solved by the invention]
[0005] The object of the present invention is to propose an update method in which the required state transitions of the individual target components are performed almost automatically. [Means for solving the problem]
[0006] This problem is solved according to the invention by a method according to claim 1 and by a safety-critical system according to claim 14.
[0007] The method according to the invention comprises the following method steps: a) an external maintenance instance requesting a system configuration update; b) the authentication unit transitioning from an "inactive" state to an "updating" state; c) a target component capable of persistent authentication being notified of the updates to be performed; d) the authentication unit performs a system integrity pre-check and triggers a first state change and version check of the persistently authenticated target component; e) the persistently attestable target component performing a version check and possibly (i.e., if necessary) a version update and reporting the results to the attestation unit; f) the authentication unit performing a system integrity check and, if the system integrity check is successful, triggering a second state change of the persistent authentication capable target component; g) the authentication unit transitioning from an "updating" state to an "inactive" state; Includes.
[0008] The method according to the invention performs secure communication between a persistently authenticated target component and a central control instance, i.e. an authentication unit, which controls and monitors the update process of the persistently authenticated target component.
[0009] The system configuration update request in step a) is preferably executed by a maintenance management component (external to the authentication unit) and then transmitted internally to the authentication unit, where the maintenance management component informs the authentication unit of the target system configuration, although the request may also be generated directly in the authentication unit.
[0010] In step c), the persistent authentication capable target components are informed about the target system configuration, in particular about which persistent authentication capable target components are included in the target system configuration. After this, preferably only the persistent authentication capable target components that are part of the target system configuration need to load data from the data repository. This information is provided to the persistent authentication capable target components either directly from the authentication unit or, preferably, from the authentication unit through a maintenance management component. In the latter case, the maintenance management component acts as a proxy between the authentication unit and the persistent authentication capable target components.
[0011] A "persistent authentication capable target component" is designed so that after one explicit authentication has been granted, it can transition to safety-critical operational behavior ("operational" state) without a new authentication, especially after a reboot. In contrast, a "connection-dependent authentication capable target component" receives an authentication for safety-critical operational behavior as soon as it is started and establishes a connection to the component according to its configuration. In this case, a new authentication is granted every time. Furthermore, the new authentication expires upon loss of connection, especially upon reboot. The authentication unit communicates with a persistent authentication capable target component.
[0012] The first combination of target components and the second combination of target components each include at least one persistent authentication-enabled target component. The combinations of start components and target components can be identical, can have an intersection, or can include completely different persistent authentication-enabled target components. Typically, the combinations of start components and target components are different from each other. Thus, a start system configuration includes persistent authentication-enabled target components that are not required in a target system configuration, and vice versa.
[0013] During maintenance periods, the authentication unit communicates with the persistently authenticated target components, preferably through a maintenance management component as a proxy. However, the authentication unit is not required during operation. Therefore, according to the present invention, the authentication unit is active only during the maintenance process, not during operation. The authentication unit must ensure the availability of all persistently authenticated target components before granting new operational authorization for the next update process, in order to prevent system inconsistencies that may occur if one or more persistently authenticated target components return to an "operational" state during later operation without performing an update. To this end, the authentication unit controls the orderly and secure state transitions of persistently authenticated target components between operational and non-operational states before and after the installation of updates. The authentication unit thereby controls the state transitions of safety-critical systems. The authentication unit ensures that persistently authenticated target components are regularly updated and in the correct state according to the target system configuration specifications, and that they receive, retain, or relinquish authentication according to the target system configuration specifications. In the method according to the present invention, the required state transitions can be automated with a high level of security. This limits human intervention to the absolute minimum necessary.The method according to the invention is scalable to a large number of system components.
[0014] In a particularly preferred variant of the method according to the invention, the external maintenance instance saves information about the target system configuration in a data repository before requesting an update in step a), so that the target component can load the data required for the update from the data repository. Preferably, the required data is loaded before the first state change of the target component capable of persistent authentication (state change to the "maintenance" state).
[0015] Preferably, the authentication unit requests secure authorization of the update request from the external maintenance instance before changing to the "update" state in (step b). The state change of the authentication unit to the "update" state is only performed upon receipt of secure authorization from the external maintenance instance. This achieves that the transmitted information cannot be tampered with. Preferably, this secure authorization is provided by the maintenance management component. The authorization must contain, in particular, information about the action to be performed (update), the configuration at start and target, the identity of the authentication unit, and a timestamp.
[0016] In a particularly preferred variant of the method according to the invention, the authentication unit analyzes the system configuration of the target. Usually, both the start and the target configuration are analyzed. In special cases, such as an initial system setup, no known start configuration exists. In this case, it is sufficient for an external maintenance unit to provide the authentication unit with assurance that this is the initial system setup and then analyze the target configuration. For analysis, the authentication unit requests data from a data repository. This is preferably done before the first state change of the persistently authentication-enabled target component is triggered.
[0017] After being notified of the update to be performed in step c), the persistent authentication capable target component can send a request to the authentication unit to enter the update phase.
[0018] Preferably, the version check and first state change of the persistent authentication capable target component is triggered in step d) by transmitting an approval to enter the update phase from the authentication unit to the persistent authentication capable target component after a system integrity pre-check, wherein the persistent authentication capable target component changes its current state to the "maintenance" state.
[0019] The system integrity pre-check preferably checks whether all persistent authentication capable target components of the starting system configuration have requested transition to the update phase.
[0020] A persistent authentication-capable target component preferably transmits its current state in the request to enter the update phase. The authentication unit authorizes the target component to start the update phase if the system integrity pre-check is successful, i.e., in the normal case, all persistent authentication-capable target components in the start configuration have transmitted requests to the authentication unit to enter the update phase. Deviating from this normal case is possible under certain preconditions, for example, when an external maintenance instance ensures that the authentication unit specifically and explicitly ensures that the persistent authentication-capable target component has been manually and persistently deactivated or placed in a "maintenance" state. Alternatively, the condition for the initiation of the maintenance phase by the authentication unit can be omitted, so that each request is responded to directly. However, this opens the possibility that individual persistent authentication-capable target components may already be in the maintenance phase, while other components are (or may be) still in operational operation. While the persistent authentication capable target component is in the first state change, the persistent authentication capable target component that is part of the starting system configuration (combination of the first target component) changes from an operational state, "operational," to a "maintenance" state, and the persistent authentication capable target component that is not part of the starting system configuration changes from an "inactive" state to a "maintenance" state.
[0021] In order for the maintenance management component to be up to date with respect to the state of the target component capable of persistent authentication, it is advantageous for the authentication unit, after receiving a request to enter the update phase, to inform the maintenance management component about the current state of the target component capable of persistent authentication and the currently installed software version.
[0022] If a persistent authentication capable target component is updated in step e), the persistent authentication capable target component that is part of the target's system configuration can install the data required for the update and request the authentication unit to terminate the update phase. Advantageously, persistent authentication capable target components that are not part of the target's system configuration are actually decommissioned and can guarantee to the authentication unit that they are decommissioned. These target components can also request the authentication unit to terminate the update phase.
[0023] In the system integrity check in step f), the authentication unit checks whether all persistently authenticated target components in the start and target system configurations are in the "maintenance" or "inactive" state. Then, the authentication unit performs persistent authentication on the persistently authenticated target components included in the target system configuration for operation in the new target system configuration. More precisely, the authentication unit checks that none of the persistently authenticated target components are in a potential operational state (i.e., they have been temporarily deactivated but are persistently authenticated, and therefore have not started operating in the old system configuration due to an uncoordinated restart of operation) or in the specific operational state of "operational." Preferably, the authentication unit checks that all persistently authenticated target components included in the start and target system configurations are in the "maintenance" state.
[0024] The second state change of the persistently authenticated target component in step f) is triggered by the authentication unit approving the end of the update phase, preferably after a system integrity check. With the departure approved, the persistently authenticated target component of the target configuration is persistently authenticated and allowed to change to the "operational" state (second state change). With the departure approved, the authentication of target components that are not included in the target system configuration is cancelled. They change from the "maintenance" state to the "inactive" state, and the operational operation of the persistently authenticated target component is stopped.
[0025] Preferably, the authentication unit is able to notify the maintenance management component of the current state of the target component capable of persistent authentication by changing to the "inactive" state in step g).
[0026] For this purpose, the authentication unit preferably creates a status report on the status of all persistently attestable target components and transmits this status report to the external maintenance instance (preferably via the maintenance management component). The status report aggregates the status information of all persistently attestable target components. The status report indicates whether the system is operational (integrity). Based on this aggregated status report, the external maintenance instance can determine whether safety-critical systems are available and which system configurations are available.
[0027] Preferably, the target system configuration remains stored in the long-term memory of the authentication unit during maintenance-free periods, at least until the next update, meaning that the authentication unit therefore only needs to be activated during maintenance.
[0028] Particularly advantageously, the method according to the invention can be used for safety-critical systems of railway signalling installations, where target components capable of persistent authentication include, for example, signalling boxes and / or radio block centres (RBC) and / or on-board units (OBU).
[0029] A safety-critical system according to the present invention includes a maintenance management component, at least one persistently attestable target component that does not require a new authentication upon reboot, and an authentication unit that is logically separated from the maintenance management component. According to the present invention, the authentication unit is configured to automate state changes of the persistently attestable target component before and after a software update. Furthermore, the authentication unit is configured to communicate with the persistently attestable target component through an SMI+ interface and to perform a version consistency check on the persistently attestable target component.
[0030] The maintenance control component alone (i.e., without the authentication unit) cannot safely introduce external information into a safety-critical system: the maintenance control component is a non-safe component (below SIL0), whereas the authentication unit meets safety level SIL4.
[0031] Unlike the traditional SMI interface, the SMI+ interface allows for the transmission of commands that guarantee integrity to a SIL4 rating. In particular, it is an SMI interface that has been extended to include version integrity checking. Essentially, other interfaces can also be used as long as they are configured to transmit commands that guarantee integrity.
[0032] The communication between the authentication unit and the target component includes, among other things, triggering a version check of the persistently authentication capable target component and receiving version control results from the persistently authentication capable target component.
[0033] In a particularly preferred variant of the method according to the invention, the maintenance management component acts as a communication interface between the persistent authentication capable target component and the authentication unit, on the one hand, and / or acts as a communication interface between an external maintenance instance and the authentication unit, on the other hand. Although the authentication unit and the maintenance management component are logically separated from each other, the authentication unit is largely transparent from the point of view of the persistent authentication capable target component with regard to communication at lower protocol layers. Thereby, in this preferred variant, the maintenance management component acts as a partner for communication with the target component (via the SMI protocol). The maintenance management component in turn forwards safety-critical maintenance requests (at the "+" part of the SMI+ interface) of the persistent authentication capable target component to the authentication unit.
[0034] In a particularly preferred embodiment of the safety-critical system according to the invention, the authentication unit also forms a secure communication interface with the external maintenance instance. The authentication unit is thus used as a proxy between the external maintenance instance and the target component of the safety-critical system. The authentication unit is configured to verify information received from the external maintenance instance and thus represents a secure endpoint for information transmitted by the external maintenance instance.
[0035] Preferably, the authentication unit is configured to be inactive during operation of the safety-critical system and to be activatable for configuring and / or updating software of target components of the safety-critical system.
[0036] To ensure that the system configuration is available as the starting system configuration at the next update, it is advantageous for the authentication unit to include a long-term memory in which the entire state of the system is stored during the maintenance-free period.
[0037] Preferably, the authentication unit is a software component based on a hardware platform, both of which have a safety level of SIL 4. Since the hardware platform is independent of the software component, it can already be present in the system and does not need to be procured separately.
[0038] In addition to the persistent authentication-capable target component, the safety-critical system according to the present invention can include at least one connection-dependent authentication-capable target component that can communicate with the persistently authenticated target component. The connection-dependent authentication-capable target component receives authentication at every reboot (connection setting specification). The authentication is valid only for the duration of the connection in the specification. The persistent authentication-capable target component can be configured to communicate with at least one connection-dependent authentication target component through an interface (e.g., an SCInat interface). The connection-dependent authentication target component is subordinate to the persistent authentication-capable target component and receives authentication from the persistent authentication-capable target component. For this purpose, the persistent authentication-capable target component controls the state transition of the connection-dependent authentication target component.
[0039] Preferably, the safety-critical system according to the invention is configured to carry out the above-described method according to the invention.
[0040] Other advantages of the present invention will become apparent from the following description and drawings. In the present invention, the above-mentioned and below-described features can be used either alone or in any desired combination. The illustrated and described embodiments should not be understood as an exhaustive list, but rather have an exemplary character for explaining the present invention. [Brief explanation of the drawings]
[0041] [Figure 1] 1 shows a schematic structure of a safety-critical system according to the present invention and an external maintenance instance; [Figure 2] FIG. 1 shows essential method steps in the method of the present invention. [Figure 3] FIG. 2 shows a detailed sequence of a particularly preferred variant of the method according to the invention by the participants in the communication; DETAILED DESCRIPTION OF THE INVENTION
[0042] FIG. 1 shows a safety-critical system SYS, in which multiple persistently attestable target components TC-A, TC-B, and TC-C are physically and logically separated (distributed). The safety-critical system SYS according to the present invention may further include a connection-dependent authentication target component TC-S. The connection-dependent authentication target component TC-S is subordinate to the persistently attestable target component (TC-A in this example). The target components TC-A, TC-B, TC-C, and TC-S each have access to configuration data D specific to each component. The safety-critical system SYS according to the present invention further includes a maintenance management component MDM and an authentication unit A. The authentication unit A is a core component of the present invention. The authentication unit A is active only during maintenance periods, but accesses a persistent memory MEM during maintenance-free periods to store the overall system state (current system configuration). The persistent memory MEM may be integrated into the authentication unit A. The authentication unit A is a platform-based software component, logically separated from the maintenance management component MDM, and communicates with the target components TC-A, TC-B, and TC-C that are capable of persistent authentication.
[0043] However, communication between the persistently authenticated target components TC-A, TC-B, TC-C and the authentication unit A takes place via the secure interface SMI+, which allows for secure transmission of data and commands. The communication is mediated by the maintenance management component MDM. The maintenance management component MDM can also communicate directly with the target components TC-A, TC-B, TC-C, TC-S via a standard interface (not shown). The maintenance management component MDM can forward additional messages for further processing to the authentication unit A via the secure interface SMI+.
[0044] Target components TC-A, TC-B, and TC-C capable of persistent authentication receive authentication from authentication unit A during system maintenance. The target components retain authentication until it is revoked again or until it abandons authentication by changing its state to "maintenance." In contrast, a target component TC-S with connection-dependent authentication receives authentication from its superior target component TC-A capable of persistent authentication when it establishes a connection with the superior target component TC-A capable of persistent authentication. Communication between the persistent authentication-enabled target components TC-A, TC-B, and TC-C and the connection-dependent authentication target component TC_S can be achieved through the standardized interface SCInat. The authentication of a connection-dependent authentication target component TC-S expires as soon as the connection with the superior target component TC-A capable of persistent authentication is terminated.
[0045] The authentication unit A is also preferably configured to act as a secure interface between the external maintenance instance M and the safety-critical system SYS, thereby ensuring that the external maintenance instance M can communicate securely with the safety-critical system SYS. The external maintenance instance M can be a human maintenance person or a maintenance computer system.
[0046] To maintain a high safety level (preferably SIL4) while updating the distributed persistently attestable target components TC-A, TC-B, and TC-C of the safety-critical system SYS, a process is required to ensure the necessary state transitions. Before the update, a transition from the system operation in the start system configuration to a non-operational state (first state change "operational" → "maintenance") is required. After the update, a transition from the non-operational state to operation in the target system configuration (second state change "maintenance" → "operation") is required. According to the present invention, an authentication unit A controls these state transitions of the persistently attestable target components.
[0047] 2 shows the essential method steps of the method of the present invention, which fulfill the above-mentioned conditions. The trigger for the update is an update request from an external maintenance instance (step a). This can be an update to an already operational starting system configuration or to the initial setup of a target configuration. In the latter case, the "starting system configuration" can be considered as not including any persistent authentication-enabled target components (i.e., all persistent authentication-enabled target components TC-A, TC-B, TC-C are in the "inactive" state). Authentication unit A is informed about the target system configuration.
[0048] To initiate the update, the authentication unit changes from the "inactive" state to the "update" state in step b), and the maintenance management component notifies the persistent authentication-enabled target component of the combination of the first and second target components about the update to be performed (step c).
[0049] In step d), the authentication unit triggers a first state change and a version check in the persistent authentication-enabled target component. The persistent authentication-enabled target component performs the version check, performs any necessary version updates, and reports the results of the version check and / or version update to the authentication unit (step e).
[0050] After successfully performing the system integrity check, authentication unit A triggers a second state change of the persistent authentication capable target components in step f), where the persistent authentication capable target components TC-A, TC-B, TC-C change their state to "operative" or "inactive" depending on whether they are included in the target system configuration.
[0051] After the update (including the state change) is finished, the authentication unit changes from the "updating" state to the "inactive" state (step g).
[0052] A particularly preferred variant of the method according to the invention is shown in detail in Figure 3. In this example, a start configuration (first target component combination) is used which includes persistently authenticated target components TC-A, TC-B, and a target system configuration (second target component combination) which includes persistently authenticated target components TC-A, TC-C.
[0053] The external maintenance instance M stores the configuration data of the target system configuration in the data repository REP of the safety-critical system SYS. The external maintenance instance M first sends an update request (step a in Figure 2) to the maintenance management component MDM. The update request is forwarded from the maintenance management component MDM to the authentication unit A. Information about the target system configuration is transmitted, in particular which persistently authentication-capable target components TC-A, TC-C are required for the target system configuration and which versions are required for the persistently authentication-capable target components TC-A, TC-C.
[0054] To ensure that no errors occur when transmitting the update request, authentication unit A can request approval from the external maintenance instance M. The information received from authentication unit A is forwarded to the external maintenance instance M together with a request to approve the validity of the information, thereby ensuring that the authentication unit has accurate information.
[0055] The authentication unit A performs the state change from "inactive" to "maintenance" (step b in FIG. 2) only upon receiving a corresponding secure authorization, preferably from an external maintenance instance M.
[0056] The maintenance management component MDM also notifies the persistent authentication-enabled target components TC-A, TC-B, and TC-C of the target system configuration (step c in Fig. 2). Each of the persistent authentication-enabled target components TC-A, TC-B, and TC-C checks whether it is included in the target system configuration. If it is, it downloads the corresponding data (especially the required software version) from the data repository REP. Preferably, only the persistent authentication-enabled target components TC-A and TC-C included in the target system configuration load data from the data repository REP. However, the persistent authentication-enabled target component TC-B that is not included in the target system configuration must at least confirm the fact that it is not included in the target system configuration, for example, by finding no entry for its own identification in the data repository REP.
[0057] Preferably, only target components TC-A, TC-B, and TC-C that are capable of persistent authentication (i.e., system components included in the start and target system configurations) are notified about the target configuration, thereby prompting them to provide information about their current state. However, it is conceivable that all system components are notified and all system components are queried about their current state.
[0058] The authentication unit A performs an analysis of the target configuration. It accesses data stored in the data repository REP. This allows the authentication unit A to compare whether the target state matches the actual state of the operational and persistently attestable target components TC-A, TC-B, and TC-C. Here, the target state can be (the start or target system configuration in the data repository). The actual state can be (the actual message requesting a transition from the start system configuration to a maintenance state (request to enter the maintenance phase) or an actual message requesting a transition to an operational state in the target system configuration (request to exit the maintenance phase)).
[0059] Before persistent authentication-enabled target components TC-A, TC-B, and TC-C start their version check, they each make a request to the authentication unit as to whether they are allowed to perform a first state change (a request to enter the maintenance phase). The persistent authentication-enabled target components TC-A, TC-B, and TC-C report their current states to the authentication unit A. Before persistent authentication-enabled target components TC-A, TC-B, and TC-C are authorized to enter the maintenance phase, the authentication unit A performs a system integrity pre-check and preferably checks whether all persistent authentication-enabled target components TC-A, TC-B in the starting system configuration have made a request to the authentication unit to enter the update phase.
[0060] For the persistently attestable target components TC-A, TC-B in the starting system configuration, the first state change means that the "operational" state is ended. Ending the "operational" state is a safety-critical process. The authentication unit A performs this process in a regulated manner (which can be defined via a set of rules). The authentication unit A performs this process by approving the persistently attestable target components TC-A, TC-B, and TC-C to enter the maintenance phase. By approving the entry into the maintenance phase, the authentication unit triggers the first state change to the "maintenance" state (step d in Figure 2) for the persistently attestable target components TC-A, TC-B, and TC-C.
[0061] Preferably, the authentication unit A informs the maintenance management component MDM (and also the external maintenance instance M) about the progress of the process, in particular about the decision to initiate a state change for the persistently authenticated target components TC-A, TC-B, TC-C (status report). Since it is possible that the persistently authenticated target components do not unexpectedly request a state transition, which is nevertheless an essential prerequisite for the rules for initiating synchronous state transitions, the authentication unit A must also report these states as part of the status report. This allows the external maintenance unit to take the necessary manual measures to resolve this irregular state. The individual states of the persistently authenticated target components TC-A, TC-B, TC-C can essentially be queried via a standardized interface (SMI).
[0062] After the first state change, the preloaded data from the data repository REP is installed (step e in Fig. 2). The target components TC-A, TC-B, and TC-C capable of persistent authentication send a request to the authentication unit A to leave the maintenance phase.
[0063] The authentication unit then performs a system integrity check (step f in Figure 2), where it checks that all persistently attestable target components TC-A, TC-B, TC-C in the start and target configurations are in the "maintenance" or "inactive" state and that the versions specified by the target system configuration are installed, respectively.
[0064] If the system integrity check indicates that all requirements are met, authentication unit A triggers a second state change of persistent authentication capable target components TC-A, TC-B, TC-C by authorizing them to leave the maintenance phase: persistent authentication capable target components TC-A, TC-C that are included in the target system configuration change to the "operative" state, and persistent authentication capable target component TC-B that is not included in the target system configuration changes to the "inactive" state.
[0065] After authorizing all persistently authenticated target components TC-A, TC-B, TC-C to leave the maintenance phase, the authentication unit A informs the maintenance management component MDM of the current state of the persistently authenticated target components TC-A, TC-B, TC-C, which change to the "inactive" state (step g in Figure 2). The maintenance management component MDM receives an aggregated status report from the authentication unit A. The aggregated status report contains status information about all persistently authenticated target components. The report can be forwarded to the external maintenance instance M as part of the update authorization.
[0066] The status report includes summarized status information for all persistently authenticated target components TC-A, TC-B, and TC-C. Thus, the status of persistently authenticated target components TC-A, TC-B, and TC-C does not need to be queried individually. To ensure that target component TC-B is no longer included in the target system configuration and has actually ceased its active operation and is in an "inactive" state, the status report preferably also includes status information for target component TC-B that is no longer participating in the target system configuration.
[0067] Furthermore, the target system configuration is persistently stored in the persistent memory MEM of authentication unit A as the new current system configuration for the next update.
[0068] Based on the status report, the external maintenance instance can decide that the safety-critical system should be put into operation again (the state of all persistently certifiable target components TC-A, TC-B, TC-C matches the target configuration or deviations therefrom are assessed as non-critical), or that a critical deviation is confirmed, for example, and that the safety-critical system should be kept out of operation.
[0069] The method according to the invention can be integrated into existing solutions (for example as known from [1]) for checking connection-dependent authenticating target components.
[0070] The authentication unit forms a secure interface with the outside world and centrally coordinates the state transitions of persistently attestable target components. The authentication unit assumes overall control for updating persistently attestable target components, triggers their state transitions, version checks and updates, collects information about the state and versions of persistently attestable target components, and creates an aggregated state report. The authentication unit checks whether all persistently attestable target components are in the target state, thereby ensuring the functional safety of the safety-critical system. Therefore, the use of the authentication unit according to the present invention enables controlled updates of safety-critical systems at a high safety level.
[0071] The integration of the authentication unit according to the present invention provides a structure for controlling orderly and secure state transitions between operational and non-operational states of safety-critical systems before and after the installation of updates. [Explanation of symbols]
[0072] D Component-specific configuration data A Certification Unit M External Maintenance Instance MDM Maintenance Management Component MEM Persistent Memory REP Data repository for system configuration TC-A Target component with persistent authentication (included in system configuration at start and target) TC-B Target components capable of persistent authentication (included in the start system configuration but not in the target system configuration) TC-C Target component capable of persistent authentication (included in the target system configuration but not in the start system configuration) Target components that rely on TC-S connections to authenticate SCInat Standardized Interface SMI+ Interface SYS Safety-critical systems
Claims
1. 1. A method for configuring and / or updating software of a target component of a safety-critical system (SYS) from a starting system configuration to a target system configuration, comprising: The safety-critical system (SYS) comprises a maintenance management component (MDM), a central authentication unit (A), and at least one persistently attestable target component (TC-A, TC-B, TC-C); the starting system configuration includes a first combination of target components (TC-A, TC-B), and the target system configuration includes a second combination of target components (TC-A, TC-C); The following method steps: a) an external maintenance instance (M) requests a system configuration update; b) the authentication unit (A) changes from an "inactive" state to an "updating" state; c) the persistent authentication capable target components (TC-A, TC-B, TC-C) are notified about the updates to be made; d) the authentication unit (A) performs a system integrity pre-check and triggers a first state change and version check of the persistently authenticated target components (TC-A, TC-B, TC-C); e) the persistently authenticated target components (TC-A, TC-B, TC-C) perform a version check and possibly a version update and report the results to the authentication unit (A); f) the authentication unit (A) performs a system integrity check and, if the system integrity check is successful, triggers a second state change of the persistently authenticated target components (TC-A, TC-B, TC-C); g) the authentication unit (A) changing from an "update" state to an "inactive" state.
2. Before requesting an update in step a), the external maintenance instance (M) stores information about the target system configuration in a data repository (REP); The target components (TC-A, TC-B, TC-C) load the data required for the update from the data repository (REP).
2. The method of claim 1.
3. said authentication unit (A) requests a secure authorization of an update request from said external maintenance instance (M) before changing to said "update" state (step b)); said state change of said authentication unit (A) to said "update" state is performed only upon receipt of secure authorization from said external maintenance instance (M); 3. The method according to claim 1 or 2, characterized in that
4. The authentication unit (A) analyzes the system configuration of the target, preferably the start configuration and the target configuration.
4. The method according to claim 1, wherein the
5. The persistently authenticated target components (TC-A, TC-B, TC-C) are: After being notified in step c) about the update to be performed, requesting the authentication unit (A) to enter an update phase; The version check and the first state change of the persistently authenticated target components (TC-A, TC-B, TC-C) are Triggered in step d) after a pre-check of the system integrity, a confirmation of entering the update phase is transmitted from the authentication unit (A) to the persistent authentication capable target components (TC-A, TC-B, TC-C), The persistently authenticated target components (TC-A, TC-B, TC-C) change from their current state to a "maintenance" state; 5. The method according to claim 1, wherein the
6. In the pre-check of the system integrity, the authentication unit (A) Check whether all persistently authenticated target components (TC-A, TC-B) of the starting system configuration have sent requests to the authentication unit (A) to enter the update phase.
6. The method according to claim 1, wherein the
7. After receiving a request to enter the update phase, the authentication unit (A) notifies the maintenance management component (MDM) of the current state of the persistently authenticated target components (TC-A, TC-B, TC-C).
7. The method according to claim 5 or 6.
8. In step e), when the persistent authentication capable target components (TC-A, TC-B, TC-C) are updated, A target component (TC-A, TC-C) capable of persistent authentication, which is part of the target's system configuration, installs the data necessary for the update and requests the authentication unit (A) to end the update phase; A persistently attestable target component (TC-B) that is not part of the target system configuration assures the authentication unit (A) that it is out of service and requests the authentication unit (A) to terminate the update phase.
8. The method according to any one of claims 1 to 7, characterized in that
9. In the system integrity check in step f), the authentication unit (A) Check that all persistently authenticated target components (TC-A, TC-B, TC-C) in the start and target system configurations are in a "maintenance" or "inactive" state before persistently authenticated target components (TC-A, TC-C) included in the target system configuration are persistently authenticated for operation in a new target system configuration.
9. The method according to any one of claims 1 to 8, characterized in that
10. Triggering the second state change of the persistently authenticated target component (TC-A, TC-B, TC-C) in step f) is performed by: This is executed by the authentication unit (A) approving the end of the update phase after checking the integrity of the system, During the second state change: A target component (TC-A, TC-C) capable of persistent authentication included in the target system configuration changes from a "maintenance" state to an "operational" state; A target component (TC-B) that is not included in the target system configuration changes from a "maintenance" state to an "inactive" state.
10. The method according to any one of claims 1 to 9, characterized in that
11. The authentication unit (A), preferably after changing to the "inactive" state in step g), notifies the maintenance management component (MDM) of the current state of the persistently authenticated target components (TC-A, TC-B, TC-C).
11. The method according to any one of claims 1 to 10, characterized in that
12. the authentication unit (A) creates a status report about the status of all persistently authenticated target components (TC-A, TC-B, TC-C) and transmits the status report to the external maintenance instance (M); 12. The method according to claim 11 .
13. The system configuration of the target is maintained and stored in the long-term memory (MEM) of the authentication unit (A) during a maintenance-free period.
13. The method according to any one of claims 1 to 12, characterized in that
14. The safety-critical system (SYS) is a railway signaling system.
14. The method according to any one of claims 1 to 13, characterized in that
15. A safety-critical system (SYS), comprising: a maintenance management component (MDM); At least one persistently authenticated target component (TC-A, TC-B, TC-C) that does not require new authentication upon restart; Equipped with The safety-critical system (SYS) comprises an authentication unit (A) logically separated from the maintenance management component (MDM), the authentication unit (A) is configured to automatically change the state of the persistent authentication capable target components (TC-A, TC-B, TC-C) before and after a software update; The authentication unit (A) is configured to communicate with the persistent authentication capable target components (TC-A, TC-B, TC-C) through an interface (SMI+) and to perform version consistency checks of the persistent authentication capable target components (TC-A, TC-B, TC-C). A safety-critical system characterized by:
16. The authentication unit (A) forms a secure communication interface to an external maintenance instance (M).
16. The safety-critical system of claim 15.
17. The authentication unit (A) configured to be inactive during operation of the safety-critical system (SYS); configured to be activatable for configuring and / or updating the software of target components (TC-A, TC-B, TC-C) of said safety-critical system (SYS); 17. A safety-critical system according to claim 15 or 16.
18. The authentication unit (A) comprises a long-term memory (MEM), which stores the entire state of the system during a maintenance-free period. A safety-critical system according to any one of claims 15 to 17, characterized in that
19. The authentication unit (A) is a software component based on a hardware platform, both of which have a security level of SIL4.
19. A safety-critical system according to any one of claims 15 to 18, characterized in that
20. The safety-critical system (SYS) comprises at least one connection-dependent authentication target component (TC-S) that communicates with one of the persistently authenticated target components (TC-A).
20. A safety-critical system according to any one of claims 15 to 19.
21. The safety-critical system (SYS) is configured to perform the method according to any one of claims 1 to 13.
21. A safety-critical system according to any one of claims 15 to 20.