Software in sicherheitsrelevanten Systemen Ralf Pinger Stefan Gerken

Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken / Helge Zücker Sommersemester 2019

Kapitel 4 - konstruktive Grundprinzipien der Sicherheit Inhaltsübersicht 1. 2. 3. 4. 5. 6. 7. Mehrkanaligkeit Diversität Voting Sicherer Zustand Fallback-Mechanismen, Redundanz Umsetzung Zusammenfassung Page 2 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 1 Mehrkanaligkeit – Prinzip Grundprinzip: § § Jede Funktion wird mehrfach realisiert und ausgeführt Die Ausführungen sind paarweise rückwirkungsfrei Folgerung: § § § Fehler werden erkannt Fehler werden offenbart Fehler werden beherrscht Page 3 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 1 Mehrkanaligkeit – Unterscheidung unabhängige Wirkmechanismen: § § Physikalisch Logisch Algorithmen Vorgehen unabhängige Ausführungspfade: § Ausfälle wirken nur in einem Kanal Page 4 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 2 Diversität – Grundpinzip Prinzip § § Eine Aufgabe wird auf unterschiedliche Art und Weise mehrfach realisiert Spezialfall der Mehrkanaligkeit Beispiele § § § Geschwindigkeitsermittlung über Tacho und Radar Prozess: SW-Entwicklung und SW-Test Coded Mono Processor Page 5 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 2 Diversität – Probleme § § § Bei festem Budget für die Entwicklung einer Funktion bleibt für jede Variante ein entsprechend kleinerer Bruchteil (für alle Phasen der Entwicklung) Gleiche Ausbildung erzeugt gleiche Weltbilder und damit ähnliche Fehler; damit ist die Annahme der Unabhängigkeit systematischer Fehler nicht gegeben Fehlerhafte Voraussetzungen werden auch hier nicht offenbart Wissenschaftliche Untersuchungen § § Nancy Leveson et al. In IEEE Transactions on Software Engineering: 1986: „An Experimental Evaluation of the Assumption of Independence in Multiversion Programming“ 1990: „The Use of Self Checks and Voting in Software Error Detection: An Empirical Study“ 1991: An Empirical Comparison of Software Fault Tolerance and Fault Elimination“ Page 6 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 3 Voting: § Mehrkanaligkeit erzeugt immer mehrere Ergebnisse § Es muss das richtige Ergebnis auf den gesteuerten Prozess wirken Annahme: § Ein Fehler wirkt sich nur in einem Kanal aus Folgerung: § Ein abweichender Kanal muss abgeschaltet werden Page 7 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 3 Voting Problem: § § Hat die Hardware physische (zufällige) Fehler? Welcher Kanal ist defekt? Lösung: § § § Man nimmt mehrere Kanäle Man versucht, einen Mehrheitsentscheid zu erwirken Wenn das nicht möglich ist, nimmt man einen sicheren Zustand ein Page 8 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 4 Sicherer Zustand Ein Zustand, von dem keine Gefährdung mehr ausgeht § Bei der Bahn im Regelfall der energielose Zustand (Stillstand) § Im Flugzeug ein Zustand, der ein sicheres Landen erlaubt Auch der energielose Zustand ist nicht immer sicher Page 9 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 5 Fallback-Mechanismen, Redundanz Rückfallebenen sind erforderlich, wenn § es keinen sicheren Zustand gibt § ein Stillstand des Betriebs zu teuer ist § eine Bergung des ausgefallenen Gerätes nicht oder nur schwer möglich ist Rückfallebenen ermöglichen daher, für eine gewisse Zeit weiterhin Betrieb zu machen ohne die Sicherheit übermäßig zu verschlechtern Page 10 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 5 Fallback-Mechanismen, Redundanz § Redundanz: zusätzlicher Kanal, der im Regelbetrieb nicht benötigt wird. Verwendung nur im Fehlerfall § Arten von Redundanz: § Hot Standby: redundanter Kanal läuft immer mit, Umschaltung kann direkt erfolgen. § Cold Standby: redundanter Kanal läuft nicht mit, Hochfahren des Systems nach Umschaltung notwendig Page 11 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung In der Literatur gibt es unterschiedliche Bezeichnungen Definition: N-out-of-M oder N-von-M (z. B. 2 oo 2 oder 2 v 2) 1. N der M Kanäle müssen funktionstüchtig sein und dasselbe Ergebnis errechnen 2. Das Ergebnis der N gleichen Kanäle wird zur Weiterverarbeitung verwendet Page 12 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – 1 oo 2, Redundanz Page 13 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – Eigenschaften von 1 oo 2 § Erhöhung der Zuverlässigkeit und Verfügbarkeit des Gesamtsystems § Doppelte Hardwarekosten § Common Cause: Gemeinsame Stromversorgung, etc. ? Page 14 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – 2 oo 2, Sicherheit Page 15 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – Voter Page 16 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – Eigenschaften von 2 oo 2 § Erkennung von Hardware-Fehlern durch Voter möglich § Bei Abweichung: sicherer Zustand § Doppelte Hardwarekosten § Common Cause: Gemeinsame Stromversorgung, etc. ? § Zuverlässigkeit und Verfügbarkeit geringer als bei einem Kanal, da beide Kanäle zwingend benötigt werden. Page 17 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – 1 oo 1 D, Sicherheit Page 18 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – Eigenschaften von 1 oo 1 D § 1 D steht für 1 Kanal + Diagnose-Kanal, in diesem Sinne eigentlich auch 2 § Diagnosekomponente führt eine Selbstprüfung durch § Falls ein Fehler erkannt wird, erfolgt die Ausführung einer Sicherheitsfunktion (z. B. Abschalten, eingeschränkte Funktion) § Fehlerhafte Ausgaben werden nicht sofort unwirksam (Diagnose muss erst arbeiten!) § Gemeinsame Hardware für Haupt- und Prüfprogramm: Was passiert wenn beide gleichermaßen versagen (Common Cause) § Überprüfung kann auch auf Ausgabebaugruppen verlagert werden § Geringe Kosten für zusätzlich Hardware, falls D einfach aufgebaut werden kann Page 19 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – 2 mal 2 oo 2, Sicherheit und Redundanz Page 20 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – Eigenschaften von 2 x 2 oo 2 § Redundanz als hot oder cold möglich § Erhöhung der Zuverlässigkeit und Verfügbarkeit des Gesamtsystems § Vierfache Hardwarekosten plus Umschaltungen § Common Cause: Gemeinsame Stromversorgung, Sensorik, Aktorik etc. ? Page 21 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – 2 x 1 oo 1 D, Sicherheit und Redundanz Page 22 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – Eigenschaften von 2 x 1 oo 1 D § Alternative Darstellung mit 1 oo 1 D § Hier als Hot-Standby-System mit Muxer realisiert. Dieser Muxer schaltet nur durch § Sicherheit steckt in den einzelnen 1 oo 1 D-Kanälen. § Realisierungsvarianten hängen Architektur, Kosten, Nutzen, Einsatzzweck usw. ab Page 23 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – 2 oo 3 Page 24 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – 2 oo 3 -Voter Page 25 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 6 Umsetzung – Eigenschaften von 2 oo 3 § Verdreifachung der HW § Fehlerhafter Kanal kann erkannt werden § Weiterarbeiten nach erstem Fehler möglich § Synchronisation noch schwieriger Page 26 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 7 Zusammenfassung - Umsetzungen § genannten Prinzipien sind nur Beispiele und können beliebig erweitert bzw. verändert werden § Notwendigkeit der einzusetzenden Architektur sollte aus einer Risiko-Analyse abgeleitet werden § Vollständige Zweikanaligkeit verringert common cause Ausfälle § Hohes Maß an Ausfalloffenbarung durch Zwei- bzw. Mehrkanaligkeit möglich § Durch HW-Vergleicher extrem schnelle Ausfalloffenbarung möglich § Unabhängiges Abschalten durch Vergleicher möglich § Natürlich können auch die Übertragungsmedien mehrkanalig ausgelegt werden! Page 27 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 7 Zusammenfassung - Allgemeines Probleme: § Enge Synchronisation und dichte Nachbarschaft der Kanäle machen das System empfindlich für common cause Einflüsse: § Einflüsse über die Peripherie § Einflüsse über die Stromversorgung § Elektromagnetische Felder § Temperatur (von außen, aber auch durch Nachbarkanal) Gegenmaßnahmen § „Sichere“ Trennung der Peripherie vom Rechnerkern § Hoch überwachte Stromversorgung § Hochwirksame Schirmung Page 28 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen

4. 7 Zusammenfassung - Allgemeines § Mehrkanaligkeit kann eingesetzt werden für: § Redundanz: Weiterarbeiten nach Ausfall von Kanälen § Sicherheit: Erkennung von physischen Fehlern der Hardware § Sicherheit und Redundanz § Architekturen müssen die Ziele sicherstellen in Bezug auf § § Page 29 R: Zuverlässigkeit A: Verfügbarkeit M: Wartbarkeit S: Sicherheit 31. 10. 2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen