SECURITY ALS BASIS SAFETY-KRITISCHER EINGEBETTER SYSTEME

Transkript

1 SECURITY ALS BASIS SAFETY-KRITISCHER EINGEBETTER SYSTEME Frederic Stumpf Fraunhofer Research Institution for Applied and Integrated Security Microprobing auf geöffnetem Chip Fraunhofer

2 AGENDA Fraunhofer AISEC Motivation Cyber Physical Systems Aktuelle Fälle Implikationen Safety und Security Vergleich Safety und Security Lösungen Eigenschaften von Safety und Security Lösungen Angriffe und Gegenmaßnahmen Problemfelder Fazit Fraunhofer 2 2

3 Joseph von Fraunhofer ( ) Forscher Erfindung von Fraunhofer Linien Im Sonnenspektrum Erfinder Neue Methoden für Linsenverarbeitung Geschäftsmann Leitung der königl. Glasfabrik Fraunhofer 3 Frederic Stumpf 3 3

4 Fraunhofer Profil in Institute 80 Forschungseinheiten An ca. 40 Orten Europa, Asien, USA Mitarbeiter 1.5 Mrd. Forschungsbudget 7 Allianzen Information und Kommunikationstechnologie AISEC deckt alle Security Aspekte ab Lebenswissenschaften Materialien und Komponenten Mikroelektronik Produktion Oberflächentechnologie und Photonik Verteidigungsforschung Fraunhofer 4 Frederic Stumpf 4

5 Fraunhofer AISEC Leitung: Prof. Dr. Claudia Eckert Prof. Dr. Georg Sigl (Stv.) Gründung: March 2009 Mitarbeiter 2011: ~60 (FTEs) Budget 2011: 3.6 Mio Forschungsschwerpunkte: Embedded Security Network Security Cloud Computing Finanzierung (Standard Modell) 33% Bund direkt 67% Drittmittel Fraunhofer 5 Frederic Stumpf 5 5

6 Motivation Zunehmende Vernetzung Safety-kritischer Systeme Systeme traditionell nur gegen Ausfälle/Fehler geschützt Keine IT-Sicherheitsmechanismen Oft wenig Resourcen / hohe Echtzeitanforderungen Durchdringung des Alltags mit Embedded Systemen Nicht nur klassische Safety-relevante Systeme sind Safety-kritisch Vernetzung mit Consumer Devices Benutzung des Internets (oder mit dem Internet verbundene Netze) als Kommunikationsinfrastruktur Fraunhofer 6 6

7 Von eingebetteten Systemen zu Cyber Physical System Privacy Non repudiation Confidentiality + Access Control Authenticity Required Security Services ES ES Bus; Serial IF Internet + Integrity Sensor µcontroller Actuator ES ES System Complexity Embedded System (ES) Locally Connected ES Cyber Physical System Fraunhofer 7 7

8 Bedrohungen durch Angriffe Alle klassischen Safety-relevanten Domänen sind aufgrund zunehmender Vernetzung betroffen: Industrieanlagen Automotive Bahn Heimautomation Energiesektor (SmardGrid) Cyber-physical systems (CPS) Zukünftig auch vermehrt Avionik Raumfahrt Fraunhofer 8 8

9 Beispiele für aktuelle Fälle: StuxNet StuxNet ist Paradebeispiel dass selbst formal isolierte Safety-Systeme von Angriffen betroffen sind StuxNet wurde erstmalig im Juni 2010 bekannt Schadprogramm speziell für Siemens S7 Steuerungssysteme Ausnutzung mehrerer teilweise bis dahin unbekannter Sicherheitslücken (Zero- Day-Exploits) von MS Windows Installation eines Rootkits mit Hilfe gestohlener digitaler Signaturen von Realtek und JMicron Technology genaue Kenntnisse des Prozessvisualisierungssystems WinCC Installation eines weiteren Rootkits in der S7-Steuerung Mögliches Ziel: Iranische Atomanlagen Nachfolger Duqu bereits aufgetaucht Fraunhofer 9 9

10 Beispiele für aktuelle Fälle: StuxNet Stuxnet zeichnet sich durch fortschrittliche und komplexe Verbreitungsstrategie aus: Über das Netzwerk Netzwerkfreigaben SQL Injection Print spooler vulnerability Windows server service vulnerability Über Wechseldatenträger.LNK files Autorun.inf Über Projektdateien Netzwerk Wechseldatenträger Projektdateien Fraunhofer 10 10

11 Beispiele für aktuelle Fälle: StuxNet Stuxnet manipuliert S7 Steuerprogramm: OB1 OB1 Stuxnet verdeckt Manipulation der Steuerung: Fraunhofer 11 11

12 Beispiele für aktuelle Fälle Insulinpumpe Fall präsentiert auf der Black Hat Security Conference 2011 in Las Vegas Insulinpumpe ist abhängig von Drahtlosschnittstelle Drahtlos-Sensoren messen Blutzuckerwerte Übermitteln Daten an Insulinpumpe Patient kann Daten überwachen und Insulin entsprechend injizieren aus Kosten- und Energiespargründen (implantiere Batterie) keine kryptographischen Mechanismen verankert Reverse-Engineering (Hilfe durch Dokumente für die Federal Communications Commission, Patente) Pumpe vollständig fernsteuerbar, Manipulation für Patienten nicht ersichtlich potentiell tödliche Dosis kann unbemerkt verabreicht werden ähnlicher Fall mit Herzschrittmacher präsentiert auf der Defcon Fraunhofer 12 12

13 Implikationen von Security auf Safety Abstrakte Definition Safety: Schutz der Umwelt vor einem technischen System Abstrakte Definition Security: Schutz des technischen Systems vor der Umwelt Eigenschaften von Safety Systemen: Systeme sollen gegen zufällig auftretende Fehler gehärtet werden (systemisch bedingte Fehler) Bei Zertifizierung wird System häufig als isolierte Einheit betrachtet Gegenmaßnahmen: Isolation, Redundanzen, CRC, Coded Processing, etc. Eigenschaften von Security Systeme : Systeme sollen gegen gezielte Angriffe gehärtet werden (nicht-systemisch bedingte Fehler) Interaktionen mit anderen Systemen (externe Kommunikationskanäle) werden berücksichtigt Gegenmaßnahmen: kryptographische Signaturen, Authentisierung, Isolation Fraunhofer 13 Frederic Stumpf 13 13

14 Auswirkungen auf Safety / Security Systeme Ereignisraum sei die Menge aller möglichen Ereignisse mit einer Auswirkung auf ein System das zu einer Einschränkung der Funktionalität führen kann Fehlereignisraum bei Safety Sytemen durch nicht-gezielte (zufällige) Fehler beschränkt: Unbekannte Ereignisse zum Teil relevant Safety Funktionen erfüllen ihre Funktionalität wie spezifiziert Fehlereignisraum bei Safety Systemen kann als Teilmenge des Fehlerereignisraums eines Security Systems aufgefasst werden Fehlereignisraum bei Security Systeme Fehlereignisraum bei Safety Systemen Unbekannte Ereignisse Fraunhofer 14 Frederic Stumpf 14

15 Ereignisse Safety Checksummen Ziel: Zufällige Veränderung eines Programmteils soll erkannt werden Lösung: Berechnung einer Checksumme über einen Programmteil oder den Inhalt eines Registers Checksumme über Inhalte von Registern Checksum Register <- F(*interrupt) Chechsum Program <- F(Program) Checksumme wird bei jeder Operation (Schreiben / Lesen) aktualisiert oder geprüft Annahme: Berechnung der Checksumme und Inhalt der Checksumme verlässlich *interrupt: F 0x F int validateregister() { if (*interrupt == 1) { printf("stop System \n"); return 0; } } 0x00 checksum: 0x32 Fraunhofer 15 Frederic Stumpf 15

16 Ereignisse Security Message Authentication Codes Ziel: Gezielte Manipulation eines Programmteils soll erkannt werden Angreifer kann: Checksummen nach Manipulation neu berechnen Verifikationsroutine für Checksumme manipulieren Lösung: Message Authentication Codes und Redundanz Kryptographisch gesicherte Signaturen MAC Register <- F(*interrupt, secret key) MAC Program <- F(Program, secret key) Verifikation mittels öffentlichem Schlüssel vor Ausführung Verteilte Verifikation des MACs (erschwert Angriff) alarm Fault Attack not authorized OK Fraunhofer 16 Frederic Stumpf 16

17 Security Tools für Safety-Systeme: Beispiel Fehlerangriffe (I) Lokale Lichtangriffe (Fehlerangriff) Einzelne Bits werden durch Induzierung von Laserlicht gekippt Auflösung im Mikrometer-Bereich Gegenmaßnahmen: Software-Gegenmaßnahmen: Kryptographische Signaturen über Software Mehrfachberechnungen (Redundanzen) Hardware-Gegenmaßnahmen: Verdoppelung von HW-Komponenten Dual-Core Technologien FA 0x00 0x Fraunhofer 17 Frederic Stumpf 17

18 Security Tools: Beispiel Fehlerangriffe (II) Bei Security Lösungen (Chipkarten) werden Fehlerangriffe berücksichtigt Prozess zur Simulation von Angriffen: 1. Hardwareentwurf 2. Gezielte Injektion von Fehlern in Daten und Programmfluss 3. Simulation der Schaltung 4. Auswertung der Simulation 5. Anpassung der Hardware und Härtung gegen Fehlerangriff Automatisiertes Testtool kann auch zu Safety Zwecken benutzt werden Fraunhofer 18 Frederic Stumpf 18

19 Angriffe auf Systeme Eingebettete Systeme sind zunehmend in einen Kommunikationsverbund integriert Austausch von Nachrichten und Ereignissen (zum Teil auch Safety- Nachrichten) Auswertung der Nachrichten und Ereignisse und Verarbeitung Bedrohungen und Auswirkungen auf Safety Systeme : durch andere Systeme im Kommunikationsverbund durch direkten Angriff auf das Safety-System Fraunhofer 19 Frederic Stumpf 19

20 Embedded Systems im Kommunikationsverbund CAN 1 CAN 2 ECU 1 ECU 6 Repräsentatives Beispiel ist das Fahrzeugnetz Viele vernetzte Steuergeräte mit unterschiedlicher Kritikalität Zertifizierung auf Steuergerät beschränkt Verbunden über einen BUS, um Nachrichten auszutauschen CAN etabliert keine Security Maßnahmen Kommunikation nicht authentisiert oder verschlüsselt Bus-Teilnehmer können Nachrichten mitlesen oder manipulieren Resultat: Manipuliertes (nicht konformes) Steuergerät kann zu einer erheblichen Funktionsstörung führen ECU 2 ECU 3 ECU 8 Gateway CAN 3 ECU 5 ECU 4 ECU 7 Fraunhofer 20 Frederic Stumpf 20

21 Angriffe auf CAN Netzwerke Komplexe Netzwerke mit unter schiedlichen ECUs Sehr komplexe Software-Stacks Software updates über OBD connector (CAN/Ethernet) Keine Zugriffsbeschränkungen Viele weitere Schnittstellen die für Angriffe ausgenutzt werden könnten Zunehmend weitere Schnittstellen, für remote Angriffe GSM/UMTS Fraunhofer 21 21

22 Einspielen von sicherheitkritische Nachrichten in CAN Fraunhofer 22 22

23 Fahrzeug-Fahrzeug Kommunikation Fahrzeuge sind vermehrt mit drahtlosen Kommunikationsschnittstellen ausgestattet Kommunikation mit Fahrzeugen und der Infrastruktur Erhöhung der Fahrsicherheit Use Cases (Auswahl): Emergency vehicle warning Electronic brake lights Stationary vehicle accident / vehicle problem / ecall Traffic condition warning, Traffic jam ahead warning, Slow vehicle warning, Hazardous Location Warning Collision risk warning Fraunhofer 23 23

24 Security Herausforderungen mit Implikation auf die Safety Security: Eingebrachte safety Nachrichten auf Basis gefälschter Vorfälle Kritische Unfälle Privacy: Positionsnachrichten von Fahrzeugen Erstellung von Fahrprofilen Trust: Wann kann man einer Safety-Nachricht vertrauen Revokationslisten <-> Nachrichten müssen isoliert verifiziert werden können Fraunhofer 24 24

25 Gegenmaßnahmen Authentisierung der Bus-Kommunikation oder mit externen Entitäten (Bspw. Fahrzeug-Fahrzeug Kommunikation) Verwendung von Secure Elements zum Nachweis der Identität eines Steuergeräts Übermittlung von Nachweisen, dass ein Steuergerät (Komponente) in einem vertrauenswürdigen Zustand ist Nachrichten werden mit Signatur versehen: Unterschiedliche Stärke der Signaturverfahren Entsprechend der Rechenleistung eines Steuergeräts Fraunhofer 25 25

26 Typischer Angriffsvektor auf Betriebssysteme Monolythische Betriebssysteme Vermehrt komplexe Software Anwendungen CPU stellt verschiedene Privilegienstufen zur Verfügung (Ringe) Software im BS wird mit höchsten Rechten ausgeführt Ausführung privilegierter Instruktionen Manipulationen im vollen Adressraum Virus, Wurm kann Buffer Overflow im Kernel ausnutzen Alle Softwarekomponenten können manipuliert werden Fraunhofer 26 26

27 Safety und Security Manipulation der Safety-Funktionen Grundsätzlich wird die Annahme vertreten dass eine Safety-Funktion sich wie spezifiziert verhält Diese Annahme gibt es im Security Bereich nicht Alle Komponenten können sich nicht-wie spezifiziert verhalten -> Security: Konglomerat von Funktionen die sich überwachen und ergänzen Sofern ein System kompromittiert wurde ist die Safety Funktion nicht mehr erfüllt Beeinträchtigung der Safety-Funktion Safety-Funktion kann durch einen indirekten Angriff beeinträchtigt werden Multi-Core Technologien führen möglicherweise zu neuen Angriffen Fraunhofer 27 Frederic Stumpf 27

28 Robuste Software Systems mittels Virtualisierung Zur Verfügungstellung eines Hypervisors zur Isolation Hypervisor ist Softwareschicht die HW partitioniert: Modifiziertes Interface zur Hardware (Virtuelle Maschine) Isolatierte Domänen in denen kritische Anwendungen ausgeführt werden können (Safety und Security) Mehrere Betriebssysteme können ausgeführt werden Ansatz ermöglicht: Angriffe einzugrenzen in einer Domäne Reduktion der Trusted Computing Base Weitere Dienste durch Hypervisor Reaktion auf invaliden Systemzustand Erkennung eines invaliden Systemnzustands Fraunhofer 28 28

29 Architecture eines Sicheren, Robusten Embedded OS Fraunhofer 29 29

30 Multi-Core Systeme ECU 1 Cache ECU 2 Cache Vermehrter Einsatz von Multi-Core Systemen Kapselung einer (safety) Anwendung auf einem Core Kompromittierter Core könnte Safety Anwendung beeinflussen CPU1 Speicherzugriffe durch kompromittierten memory Prozess CPU1 VM1 HW shared VM2 execution stalling memory CPU2 Fraunhofer 30 30

31 Ziele von Safety und Security Widersprüchliche Ziele: Echtzeitanforderungen vs. Kryptographie Berechnungsdauer Testbarkeit vs. Geheimhaltung Testschnittstellen Secure Memory Gemeinsame Ziele: Isolation von Komponenten Hardware ( Verteilte Systeme) Software ( Virtualisierung) Fehlertoleranz Fehler können zu Sicherheitslücken führen Funktionale Korrektheit Integrity Fraunhofer 31

32 FAZIT In vernetzten Systemen ist Security eine Prämisse für Safety-Systemen Durch Angriffe kompromittierte Safety-Systeme erfüllen nicht mehr die Safety Eigenschaften Methoden aus der Security können zur Härtung der Systeme ebenfalls im Safety-Bereich Anwendung finden Herausforderungen ergeben sich wenn Safety und Security widersprüchliche Ziele haben Real-Time Fähigkeit Reaktionen auf Vorfall (Bei Security wird System nach Detektion eines Vorfalls in Haltezustand gesetzt) Auch Angriffe und Multi-Core Systeme führen zu neuen Herausforderungen Fraunhofer 32 32

33 Thank you for your Attention Dr. Frederic Stumpf Head of Department Embedded Security and Trusted OS Telephone: Fax: Internet: Fraunhofer