Detailseite
Projekt Druckansicht

Sicherheit (Security) und Integrität

Fachliche Zuordnung Sicherheit und Verlässlichkeit, Betriebs-, Kommunikations- und verteilte Systeme
Rechnerarchitektur, eingebettete und massiv parallele Systeme
Förderung Förderung von 2013 bis 2018
Projektkennung Deutsche Forschungsgemeinschaft (DFG) - Projektnummer 206480214
 
Erstellungsjahr 2020

Zusammenfassung der Projektergebnisse

The CCC Research Unit involves the coordination of a great number of stakeholders with the goal of allowing incremental change in vehicular platforms. Within this framework, security plays an important role as it provides a stable base on which the other projects can build up-on. Assumptions about any aspect of a vehicular system can be violated by the interference caused by an attacker. For example, traditional safety analysis looks at probabilities of events occurring, but an attacker can change the odds breaking assumptions and thus making the safety analysis irrelevant. With this in mind, the key objective of the B4 Security and Integrity project is to ensure the security of software components and the security of the communications between components. Given the complexity of modern software, the existence of bugs should be considered a certainty. A sizable percentage of these bugs introduce security vulnerabilities that can be expected to be exploited by attackers. An important observation is that irrespective of the outcome of an attack, the process used by the attacker influences the behavior of that component. This off-nominal behavior may result in missed real-time deadlines, increased CPU load, even a temperature increase in the CPU core as more processing resources are consumed during or after an attack. Once a compromised component is detected, the attack must be prevented from spreading to the rest of the system. Thus, containment of any affected components is key to the survivability of complex systems, as in most cases mechanisms exist to disable components or sub-systems so that the system can continue to operate even if in a degraded manner. We enforce containment at two levels, the execution environment level, preventing an errant component from attacking other components operating within the same hardware platform (e.g. ECU) and at the network level, enforcing communications only between authorized components while employing data integrity mechanisms in the communication between components, even if they run on different ECUs. However, a heavy-handed system of a potential compromise before an actual security violation occurs. In this way, we can observe the suspect component as it operates within the Red Zone, and characterize the event. In the case of an actual attack we may use the gathered data for digital forensic analysis. This will enable us to adapt our security mechanisms to the particular attack and thus either detect it earlier, or deflect it altogether. Alternatively, if the off-nominal condition turns out to be not the result of an attack, we can allow the component to exit the Red Zone and return to its normal mode of operation. As in the case of an actual attack, the data gathered will allow us to adjust the system so that if the event re-occurs it will be handled without raising a (false) alarm. Once a software component is found to have violated its security boundaries, the system needs to take some remedial action. The type of response, e.g. taking the component off-line, restarting the component, initiating containment measures (e.g. restarting the entire ECU) and so on, are the responsibility of the Intrusion Response System (IRS). We used the Red-Zone principle as the basis for developing an IRS framework and to manage the interaction between security and safety (i.e. projects B4 and B3). Finally, a supplemental grant was used to develop coding techniques to allow recovery of damaged encrypted data frames.

Projektbezogene Publikationen (Auswahl)

 
 

Zusatzinformationen

Textvergrößerung und Kontrastanpassung