Software in sicherheitsrelevanten Systemen Ralf Pinger Stefan Gerken

Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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

4. 6 Umsetzung – Voter Page 16 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

4. 6 Umsetzung – 1 oo 1 D, Sicherheit Page 18 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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

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

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015

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 11/2/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2015