SEIS Statusseminar. Security der Middleware für IP-basierte Bordnetzarchitekturen SEIS AP 4.3. Alexandre Bouard BMW Forschung und Technik

Größe: px

Ab Seite anzeigen:

Download "SEIS Statusseminar. Security der Middleware für IP-basierte Bordnetzarchitekturen SEIS AP 4.3. Alexandre Bouard BMW Forschung und Technik 20-09-2011"

Ingelore Berg
vor 8 Jahren
Abrufe

1 SEIS Statusseminar Security der Middleware für IP-basierte Bordnetzarchitekturen SEIS AP 4.3 Alexandre Bouard BMW Forschung und Technik Seite 1

2 Agenda. Ziele des AP4.3 Sicherheit der Middleware Motivation: Angriffsszenarien und Sicherheitsanforderungen Sicherheits-Middleware-Architektur Sicherheitslösungen für MW-Dienste Exemplarische Darstellung der Funktionsweise Verwandte Projekte und Ausblick Seite 2

Middleware Definition Kommunikationsdienste für verteilte Anwendungen Bietet eine einheitliche API für Anwendungsentwickler Setzt auf Netzwerkprotokollen und

3 Middleware Definition Kommunikationsdienste für verteilte Anwendungen Bietet eine einheitliche API für Anwendungsentwickler Setzt auf Netzwerkprotokollen und Netztechnologie auf App. App. App. App. Unique MW-API Middleware Service Request TCP/IP Stack TCP/IP Stack Packet Transmission Client Physical Connection - Ethernet Server Seite 3

4 Ziel des Arbeitspakets. Definition einer Sicherheitsschicht für eine IP-basierte Fahrzeugmiddleware Sicherheitsmechanismen für Middleware-Dienste (RPC, Pub/Sub, SD) Basis für die Aufbau von sicheren Kanälen zwischen Inter- und Intra-ECU Prozessen Konzepte Policy Management Key Distribution Authentication Management Secure Hardware Management Intrusion Detection Seite 4

5 Motivation: Angriffsszenarien. A system without an adversary definition cannot be secured. Virgil Gligor Haupt-MW-Angriffe Einführung von illegal ausführbarem Code mittels Software- und Hardware-Manipulation Authentifizierungsangriffe Vertraulichkeits- und Integritätsangriffe DoS-Angriffe Angreiferfähigkeiten Abhören der Kommunikation (internes und externes Netzwerk) Nachrichten-Einspeisung, wiederholtes Abspielen (Replay) Kompromittierung von Software- und Hardware-Funktionen Seite 5

6 Sicherheitsanforderungen. Pflichtziele Authentifizierung: Prozess für beidseitige Authentifizierung Integrität: Schutz gegen unautorisierte Veränderungen Vertraulichkeit: Verschlüsselte Kommunikation gegen Abhören der Kommunikation Verlässlichkeit: Robustheit des Systems gegen Angriffe Autorisierung: Regulierter Zugriff zur Systemressourcen Optionale Ziele Nichtabstreitbarkeit: für externe Kommunikation zur Nachweisbarkeit von Transaktionen Privatsphäre: für externe Kommunikation, Pseudonymität von jedem Kommunikationsgerät (Fahrzeug-AP, CE-Gerät ) Seite 6

7 Sicherheits-Middleware-Architektur (1/2). Architekturkonzept Modularisierung Austauschbarkeit Abstraktion von Schnittstellen Konfigurierbarkeit Komponenten Security Stub: einheitliche Schnittstelle für Sicherheitsanforderungen von MW-Diensten und Anwendungsentwickler Security Framework: Abstraktionsschicht vom Sicherheitsdienst für die Ausführung von Sicherheitsmechanismen Seite 7

8 Sicherheits-Middleware-Architektur (2/2). Modularisierung der Sicherheitsdienste pro Security-Domain Framework bietet Intermodulverbindungen Konkrete Sicherheitsmechanismen sind in Plug-Ins gekapselt Seite 8

9 Sicherheitslösungen (1/2). Kommunikation zwischen 2 internen Diensten Aufbau eines sicheren Kanals (Client-Seite) Seite 9

10 Sicherheitslösungen (2/2). Kommunikation Fahrzeugnetzwerk/Außenwelt über Proxy Abgrenzung aufgrund der Fahrzeuganforderungen Sicherung, Ressourcenbeschränkung, Aufstartzeit, Leistungseinsparung MW-System wird während der Produktion konfiguriert. Im Feld ist die Konfiguration grundsätzlich statisch. Dynamisch updatebar für dedizierte Security-Funktionen Entkopplung der Sicherheitsmechanismen zwischen Fahrzeugnetzwerk und Außenwelt Aufbau unterschiedlicher sicherer Kommunikationskanäle zum Proxy und fahrzeugintern einheitliche Security zur Kommunikation Seite 10

11 Darstellung der Funktionsweise mit einem Demonstrator. Use-Case: CE-integration und Automotive mobile App Security Demonstrator Ablauf: Aufbau von internen sicheren Kanälen (1) Aufbau von Vertrauensbeziehungen mit einen Außengerät (2) Aufbau von sicheren Kanälen mit der Umweltzone (3) Seite 11

12 Verwandte Projekte. EVITA IP nicht betrachtet Sicherheit der Middleware-Dienste nicht betrachtet Fokus auf Modular-Security-Framework für Fahrzeuganwendungen OVERSEE (Open VEhiculaR SEcurE platform) Fokus auf Sichere Virtualisierungskonzepte Schnittstellen zwischen Fahrzeug- und externen Netzwerke Hardware-Security-Module basierte Sicherheitsdienste Sowohl IP betrachtet als auch Bus-Protokolle Nutzung des EVITA-Konzepts (HSM) Seite 12

13 Zusammenfassung und Ausblick AP 4.3 definiert eine: Sicherheits-Middleware für IP-basierte Bordnetzte Sichere Entkopplung zwischen fahrzeuginterner und externer Kommunikation Einbindung eines modularen Security-Frameworks zur Absicherung der Middleware-Dienste (RPC, Pub/Sub und Service Discovery) der Middleware-Kommunikation über Sicherheitszonen hinweg CE-Demonstrator zeigt: Sichere Anbindung von mobilen Endgeräten Entkopplung der Kommunikation über den Security-Proxy Nächste Schritte: Finalisierung des AP43. Ergebnisdokuments mit Spezifikation der Sicherheitskomponenten Möglicher Protokollablauf zwischen den Sicherheitskomponenten Seite 13

14 Back-up. opensecureconnection (Server-Seite) Seite 14

15 Sicherheitslösungen. Kommunikation zwischen 2 internen Dienste opensecureconnection (Server-Seite) Seite 15

Ähnliche Dokumente

Bausteine eines Prozessmodells für Security-Engineering

Bausteine eines Prozessmodells für Security-Engineering Ruth Breu Universität Innsbruck M. Breu Mai-03/1 Motivation Entwicklung einer Methode zum systematischen Entwurf zugriffssicherer Systeme Integration