Project Details
Projekt Print View

Security and Integrity

Subject Area Security and Dependability, Operating-, Communication- and Distributed Systems
Computer Architecture, Embedded and Massively Parallel Systems
Term from 2013 to 2018
Project identifier Deutsche Forschungsgemeinschaft (DFG) - Project number 206480214
 
Final Report Year 2020

Final Report Abstract

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.

Publications

 
 

Additional Information

Textvergrößerung und Kontrastanpassung