Software in sicherheitsrelevanten Systemen Ralf Pinger Stefan Gerken

Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013

Kapitel 1 - Was sind Sicherheit und Verfügbarkeit? Inhaltsübersicht 1. Motivation 2. Definitionen 3. systematische und zufällige Fehler Page 2 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Der 1. Vorfall Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 29. 06. 2000 Page 3 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Das Signal dient zur Informationsübermittlung an den Zug und übermittelt z. B. § § § Page 4 Erlaubnis zur Einfahrt erlaubte Geschwindigkeit … 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Die Weiche Page 5 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn PZB – Indusi § § § Page 6 Punktförmige Zugbeeinflussung – PZB (induktive Zugsicherung) Vermeidung von Gefährdungen und Unfällen durch Zwangsbremsung Übertragung der Signalstellung an der Strecke auf das Fahrzeug punktförmig, da nur an bestimmten Punkten eine Beeinflussung stattfinden kann PZB lediglich Unterstützung des Fahrers 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Funktionen der Indusi § Die Wachsamkeitsprüfung überwacht, dass der Triebfahrzeugführer (Tf) beim Passieren eines Halt ankündenden Signals die Aufnahme des Signalbegriffs durch eine Tastenbedienung bestätigt. § Die Bremswegüberwachung überwacht den Bremsvorgang vor einem Halt zeigenden Signal. Dies erfolgt fahrzeugseitig durch diskrete Prüfpunkte (bei Altsystemen) oder kontinuierliche Überwachungskurven. § Die Fahrsperre löst beim Passieren eines Halt zeigenden Signals eine Zwangsbremsung aus. Page 7 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Beispielstrecke Page 8 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Wirkprinzip der PZB/Indusi Page 9 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Die „Nachrichten“ der PZB/Indusi lauten: • 500 -Hz-Magnete • Ist 250 bis 150 m vor Hauptsignalen, die besondere Gefahrenpunkte decken. • falls zu schnell, erfolgt Zwangsbremsung • 1000 -Hz-Magnet • Ist am Vorsignal bzw. Überwachungssignal eines Bahnübergangs • Wachsamkeitstaste innerhalb 4 s betätigen, sonst Zwangsbremsung • falls zu schnell, erfolgt Zwangsbremsung • 2000 -Hz-Magnet • Ist am Hauptsignal • Zwangsbremsung falls Halt-Signal Page 10 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Französische Alternative zur Indusi § § Krokodil (1920 er Jahre) Signalbegriff wird als positive oder negative Spannung dargestellt (Spannung ca. +/- 20 V) Page 11 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Europäische Alternative zur Indusi § § Eurobalisen Übertragung von Datenpaketen möglich (mehrere Bytes) Übertragung von Fahrprofilen möglich Verbesserte Ortung möglich Page 12 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Bahn Punktförmige Zugsicherung Live-Demo TBL 1+ (TBL 1+ ist ein Zugsicherungssystem der belgischen Bahn) Page 13 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Fortsetzung des 1. Vorfalls Was geschah § S-Bahn 5711 stand ab 09: 53 Uhr abfahrbereit vor Ausfahrsignal, geplante Abfahrt 10: 10 Uhr § S-Bahn 5712 hat 7 Minuten Verspätung, erwartete Ankunftszeit 10: 11 Uhr § S-Bahn 5712 erhält Erlaubnis zur Einfahrt in Bahnhof § S-Bahn 5711 steht vor Halt zeigendem Signal! Page 14 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Fortsetzung des 1. Vorfalls Ausgangssituation beim Zusammenstoß zweier S-Bahnen im Bahnhof Flughafen Hannover-Langenhagen, 29. 06. 2000 Page 15 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Fortsetzung des 1. Vorfalls Was ist passiert? • S-Bahn 5711 startet um 10: 10 Uhr • Ausfahrsignal für S-Bahn 5711 stand auf Halt • Indusi erzeugt Zwangsbremsung für S-Bahn 5711 • Triebfahrzeugführer von S-Bahn 5711 drückt Freitaste und fährt wieder los! • S-Bahn 5711 fährt die Einfahrweiche auf • S-Bahn 5712 war zu diesem Zeitpunkt schon an seinem Einfahrsignal vorbei • • -> keine ZB mehr möglich! Noch im Tunnel stoßen S-Bahnen 5711 und 5712 frontal zusammen Page 16 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Fortsetzung des 1. Vorfalls Unfallfolgen: • 16 Personen verletzt • 3. 600. 000 DM Sachschaden • Wiederinbetriebnahme der Strecke erst am 30. 06. 00, 04: 00 Uhr, einen ganzen Tag später Page 17 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Fortsetzung des 1. Vorfalls Fazit: • keine kausale Beteiligung technischer Komponenten/Einrichtungen • S-Bahn 5711 erhielt Zwangsbremsung • Ursache: unerlaubte Weiterfahrt von S-Bahn 5711 • Auszug aus Regelwerk: • „Ist ein Zug an einem Halt zeigenden Hauptsignal (. . . ) unzulässig vorbeigefahren, ist nach dem Anhalten der Fahrdienstleiter sofort zu verständigen. Dies gilt auch bei einer Zwangsbremsung durch PZB an einem Hauptsignal (. . . ), das eine Fahrtstellung (. . . ) zeigt. “ Menschliches Versagen als Ursache Page 18 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Fortsetzung des 1. Vorfalls Weiteres Fazit: • Das Sicherungssystem hat die Fehlhandlung des Triebfahrzeugführers erkannt • Das Sicherungssystem hat eingegriffen • nach erfolgter technischer Reaktion übernimmt der Mensch wieder die Verantwortung • offenbar hat der Mensch die Zwangsbremsung nicht dem Hauptsignal zugeordnet Page 19 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Fortsetzung des 1. Vorfalls Mögliche Gründe für Zwangsbremsung § Indusi am Halt-Signal (Indusi) § Sicherheitsfahrschalter (Sifa) – Totmannknopf § Zurückrollen des Zuges § Störung im Fahrzeuggerät § Zwangsbremsung unbekannter Ursache Page 20 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Systemkomplexität Ist menschliches Versagen als Unfallursache vorprogrammiert? § 22 aktenkundige Fälle zwischen 1994 und 2000: Tf fährt nach Zwangsbremsung durch Indusi unerlaubt weiter! § Forderung nach optischer Signalisierung bei „ZB durch Indusi“ Systeme müssen von Menschen beherrscht werden und nicht umgekehrt! Page 21 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Systemkomplexität Page 22 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Der Vorfall in Genthin 1939 Betriebliche Randbedingungen § 22. 1939: D 10 Berlin – Köln fährt in Brandenburg Reichsbahn mit 12 Minuten Verspätung ab (viele Reisende, lange Zeit für Aus- und Einsteigen) § D 10 muss bei Kade halten, da sich im Abschnitt davor (Genthin) noch der Militärzug 176 befindet § D 10 hat damit 27 Minuten Verspätung Page 23 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Der Vorfall in Genthin 1939 Der Ablauf § D 180 Berlin Neunkirchen (Saar) folgt D 10 § D 180 lief auf und wurde mehrfach „gestutzt“ (Vorsignal auf Halt, Hauptsignal dann aber auf Fahrt) § Lokführer von D 180 „übersieht“ im Nebel Halt zeigendes Vorsignal und Hauptsignal bei Belicke § Fahrdienstleiter gibt Haltsignale und benachrichtigt Schrankenbude 89 und Stellwerkswärter in Genthin Ost § D 180 sieht nun nur noch „Fahrt“-Signale – die von D 10! Page 24 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Der Vorfall in Genthin 1939 Der Ablauf § Wärter in Schrankenbude 89 schwenkt Kreiselsignal („Halt“), Knallkapseln konnte er nicht mehr auslegen § Lokführer sieht den Wärter nicht, da dieser zu tief steht § Wärter in Genthin Ost könnte D 180 noch stoppen – er hat höhere Position Page 25 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Der Vorfall in Genthin 1939 Das Verhängnis in Genthin Ost § Stellwerkswärter reagiert überstürzt auf Meldung vom Blockwärter Belicke § Gibt Schutzhaltesignal mit elektrischer Signallampe (kreisförmig schwingend) § Er vergisst die Signale auf Halt zu stellen § D 10 sieht die Warnlampe, die für D 180 bestimmt war § D 10 leitet Schnellbremsung ein § D 180 hat „Fahrt-frei“ nach Genthin (von D 10) Page 26 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Der Vorfall in Genthin 1939 Die Unfallfolgen § D 180 fährt mit 100 km/h auf den im Bahnhof stehenden D 10 auf § 186 Menschen sterben § 106 Menschen verletzt Größte Eisenbahnkatastrophe in Deutschland Zufall oder nicht? § weiterer Unfall in derselben Nacht mit 101 Toten, 28 Verletzten Page 27 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Der Vorfall in Genthin 1939 Ursachen § menschliches Versagen des Lokführers von D 180 (Halt-Signal übersehen) § menschliches Versagen des Stellwerkwärter Genthin Ost – Verwechselung von D 10 mit D 180, keine Signal-Halt-Stellung Kette von menschlichen Fehlleistungen führte zum Unfall Page 28 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Der Vorfall in Genthin 1939 Hätte Genthin verhindert werden können? § Indusi bereits in den 20 er Jahren erprobt § 1939 war die Indusi schon weit verbreitet § Strecke war mit Indusi-Spulen ausgestattet § Einrichtung an der Lok von D 180 fehlte, da zur Reparatur! § Aufgrund von Lokmangel (Kriegszeiten) wurde die Lok trotzdem eingesetzt! Urteil: § Lokführer wurde zu 3 Jahren Gefängnis verurteilt! Page 29 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation Einfluss von Software auf Unfälle § reine Software-Fehler können ebenfalls Ursachen für Katastrophen sein § Beispielsweise Fehlfunktion im Fahrzeuggerät keine Bremsung § Funktioniert die Software beim automatischen Fahren? § Kann man überlappende Fahrstraßen im Stellwerk einstellen? Page 30 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 1 Motivation – Die Vorlesung § Wie entwickelt man Software, die in sicherheitsrelevanten Systemen ausgeführt wird? § Nicht Inhalt dieser Vorlesung: Page 31 § Entwicklung sicherer Hardware § Entwurf sicherheitsrelevanter Betriebskonzepte § Ergonomie sicherheitsrelevanter HMI 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen RAMSS Page 32 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen Zusammenhänge RAMSS und Gefährdung Page 33 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen Die Domäne als Biotop § Jede Domäne hat eigene Begriffe, die sich in Details unterscheiden § Jede Domäne hat eigene Vorgehensweisen, die sich im Detail unterscheiden § Jede Domäne hat das Ziel der funktionalen Sicherheit Die Verfahren und Vorgehensweisen ähneln sich, so dass das Verständnis von RAMSS übertragbar ist, die Methoden aber im Detail anders gewichtet und angewendet werden. Damit ist aber nicht zwangsläufig eine andere Wirksamkeit verbunden Hier also Definitionen der Bahntechnik (CENELEC) Page 34 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – Sicherheit (EN 50126) § Das Nichtvorhandensein eines unzulässigen Schadensrisikos (kurz: Freiheit von nicht akzeptablen Risiken) Sicherheit nach Mü 8004: Die Fähigkeit einer Sicherungsanlage, bei § bestimmungsgemäßem Einsatz, § ordnungsgemäßer Instandhaltung und § vorschriftsmäßiger Handhabung während einer vorgegebenen Brauchbarkeitsdauer Gefährdungen durch Funktionsversagen in dem Umfang, der nach dem Stand der Technik erforderlich ist, auch dann zu verhindern, wenn Bauelementeausfälle und Störungen in der zu Beanspruchungsbeginn als fehlerfrei angesehenen Sicherungsanlage eintreten. ” D. h. eine Anlage ist (im Sinne der Mü 8004) sicher oder nicht. Page 35 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – Gefährdung, Gefahr Gefährdung § Keine explizite Definition in der Norm § Sprachlich: Eine gefährliche Situation Gefahr (EN 50126) § Eine physikalische Situation, die potentiell einen Schaden für den Menschen beinhaltet. Page 36 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – Risiko (EN 50126) § Die Wahrscheinlichkeit des Auftretens einer Gefahr, die einen Schaden verursacht, sowie der Schweregrad eines Schadens Vereinfacht: Risiko = Schadensausmaß * Schadenshäufigkeit Page 37 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – Zuverlässigkeit (EN 50126) § Die Wahrscheinlichkeit dafür, dass eine Einheit ihre geforderte Funktion unter gegebenen Bedingungen für eine gegebene Zeitspanne (t 1, t 2) erfüllen kann. [IEC 60050(191)] Mögliche Anforderung: § § Mean Time Between Failure (MTBF) Mean Time To Failure (MTTF) Mean Up Time (MUT) Mean Distance Between Failure (MDBF) Page 38 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – Zuverlässigkeit Page 39 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – Verfügbarkeit (EN 50126) § Die Fähigkeit eines Produkts, in einem Zustand zu sein, in dem es unter vorgegebenen Bedingungen zu einem vorgegebenen Zeitpunkt oder während einer vorgegebenen Zeitspanne eine geforderte Funktion erfüllen kann unter der Voraussetzung, dass die geforderten äußeren Hilfsmittel bereitstehen. Mögliche Anforderung: § A = MUT/(MUT + MDT); 0 ≤ A ≤ 1 mit § MUT = Mean Up Time § MDT = Mean Down Time Page 40 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – Instandhaltbarkeit (EN 50126) § Die Wahrscheinlichkeit, dass für eine Komponente unter gegebenen Einsatzbedingungen eine bestimmte Instandhaltungsmaßnahme innerhalb einer festgelegten Zeitspanne ausgeführt werden kann, wenn die Instandhaltung unter festgelegten Bedingungen erfolgt und festgelegte Verfahren und Hilfsmittel eingesetzt werden. [IEC 60050(191)] Mögliche Anforderung: § § Mean Down Time (MDT) Mean Time Between Maintenance (MTBM) Mean Distance Between Maintenance (MDBM) Mean Time To Repair (MTTR) Page 41 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – System Safety Anderes Beispiel - MIL-STD-882 C § System Safety: The application of engineering and management principles, criteria, and techniques to optimize all aspects of safety within the constraints of operational effectiveness, time, and cost throughout all phases of the system life cycle. § Purpose of Software System Safety Handbook (MIL-STD) Provide management and engineering guidelines to achieve a reasonable level of assurance that software will execute within the system context with an acceptable level of safety risk. Page 42 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – System § EN 50129: § System ist: Eine Menge von Teilsystemen, die entsprechend einem Entwurf zusammenwirken. § Teilsystem ist: Ein Teil eines Systems, der eine spezielle Funktion erfüllt § Element ist: ein Teil eines Produktes, der als Grundeinheit oder Grundbaustein bestimmt wurde. Ein Element kann einfach oder komplex sein. § MIL Std 882 C § System: A composite, at any level of complexity, of personnel, procedures, materials, tools, equipment, facilities, and software. The elements of this composite entity are used together in the intended operational or support environment to perform a given task or achieve a specific purpose, support, or mission requirement. § Subsystem: An element of a system that, in itself may constitute a system. Page 43 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen – System § ISO 9000 § Systembegriff bezieht sich auf die Wechselwirkung von Prozessen Problem: Die Definition von Begriffen wie System oder Funktion ist willkürlich, . . . und wahrscheinlich wird niemals eine universelle Definition gelingen. ABER: Die Sicherheit darf nicht davon abhängen, ob eine Funktion von einem „System” oder „Element” erbracht wird oder gar nur von einer Definition. Page 44 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen System - Eigenschaften § Die Hauptaufgabe ist die Entwicklung hinreichend gefährdungsfreier Produkte. Die Sicherheit sollte nicht davon abhängen, ob eine Funktion von einem „System” oder „Element” erbracht wird. Daraus folgt: Der Benutzer muss das zu betrachtende „System” klar und eindeutig definieren. Ein (Sub-)System zeichnet sich dadurch aus, dass es sich von der Umgebung abgrenzen lässt (also Systemgrenze und Schnittstellen bekannt sind), und dass es eine wohldefinierte (beabsichtigte) Funktion erbringen soll Page 45 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen System - Eigenschaften Page 46 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 2 Definitionen System – Checkliste § Ist die Systemgrenze klar definiert? § Sind an der Systemgrenze die Schnittstellen definiert? § Sind die Ein- und Ausgaben auf diesen Schnittstellen definiert? § Ist die Aufgabe, die das System erfüllen soll, klar definiert? § Sind die Einsatzszenarien bekannt und dokumentiert? § Ist die Systemstruktur beziehungsweise Systemarchitektur dargestellt? § Sind die einzelnen Architekturelemente definiert? § Ist ihr Zusammenwirken eindeutig definiert? Page 47 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 3 RAMSS für Systeme/Produkte Was bedeutet RAMSS für Eisenbahnsignaltechnik? § Zwingend notwendige Produkteigenschaften, ohne deren Nachweis die Produkte nicht marktfähig sind § Funktionsversagen kann katastrophale Folgen haben (Unfälle) § Mangelnde Verfügbarkeit wird pönalisiert § Das behauptete Sicherheitsniveau ist weder durch Gebrauch noch Test positiv nachweisbar § Security wird bisher als Problem unterschätzt Page 48 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 3 Sicherheit von Systemen/Produkten Wann ist etwas sicher? w Wie sicher sind die Komponenten bzw. Anlagen? w Wie sicher müssen die Komponenten bzw. Anlagen sein? w Wie kann die Sicherheit glaubhaft gemacht werden? w Warum ist die eingesetzte SW/HW frei von Fehlern? w Auf welche Betrachtungseinheit bezieht sich die Sicherheit? w Was ist überhaupt ein Fehler? Page 49 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 3 Anforderungen und Sicherheitsanforderungen Page 50 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 3 Systematische und physische (zufällige) Fehler Klassifikation von Fehlern § Physische (zufällige) Fehler § Hardwarefehler als Folge von Alterung § Verschleiß § ausgefallene Transistoren Ursache: Physik § Systematische Fehler § mangelhafter Entwurf § Programmierfehler § fehlerhafte Dimensionierung der Hardware Ursache: Mensch Page 51 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 3 systematische und physische Fehler Klassifikation von Fehlern § Unterscheidung § § § systematische Fehler treten nach Beseitigung nicht mehr auf physische Fehler können sich jederzeit wiederholen Übergang kann fließend sein: Unterdimensionierter Kühlkörper eines Transistors Aber: eigentlich ist das ein systematisches Problem Mögliche Ursache? Page 52 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 3 systematische und physische Fehler Folgerung: § Hardware § § § physische Fehler möglich systematische Fehler möglich Software § § Page 53 physische Fehler nicht möglich systematische Fehler möglich 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

1. 3 systematische und physische Fehler Für diese Vorlesung folgt daraus: § § Entwicklung von Software, die für die Ausführung auf einer Hardware gedacht ist, die sich für die Ausführung von Sicherheits-Funktionen eignet. Vermeiden von systematischen Fehlern in der Software Für sicherheitsrelevante Hardware folgt daraus: § § § Erkennen von physischen Fehlern Beherrschen von physischen Fehlern (falls vorhanden einen sicheren Zustand einnehmen) Vermeiden von systematischen Fehlern Wohldefiniertes Verhalten (und auch dokumentiert) Nicht Inhalt dieser Vorlesung Page 54 12/5/2020 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013