Anhand einiger typischer Szenarien werden sowohl die Möglichkeiten als auch die technischen Anforderungen einer Virtualisierung dargestellt. Das sind die Punkte:
Angriffe auf die E/E-Infrastruktur von Fahrzeugen sind durch den aktuellen Vernetzungsgrad heute leichter durchzuführen als noch vor einigen Jahren; folglich hat das Interesse an diesen Angriffen deutlich zugenommen. Als Negativbeispiel sei eine Veröffentlichung universitärer Forscher aus dem Jahr 2011 angeführt. Anhand eines US-amerikanischen Mittelklassewagens zeigten sie, wie leicht Fahrzeuge auch ohne physikalischen Zugriff kompromittiert werden können. Für eine Schwachstellenanalyse wurden die Speicherbausteine der Steuergeräte entnommen, der Binär-Code direkt ausgelesen und auf potentielle Fehler untersucht. Dabei fanden die Forscher diverse Sicherheitslücken wie Buffer-Overflow-anfällige Funktionen, offene serielle Schnittstellen, zurückgelassene Debug-Informationen und selbst dem Hersteller nicht weitergemeldete und undokumentierte Steuerbefehle zum Laden eigener Software. Für einige der gefundenen Lücken wurden auch real funktionierende Angriffe implementiert. So kann allein über einzelne modifizierte WMA-Musikdateien Root-Zugriff erlangt werden.
Wie erwartet, erwiesen sich besonders Funkschnittstellen als problematisch: Das System ließ sich über Bluetooth sowie über eine fehlerhafte GSM/CDMA-Integration kompromittieren. Durch eine starke Vernetzung der Head-Unit mit anderen Steuergeräten erlangt man praktisch Vollzugriff auf das Fahrzeug: Abhören über das Mikrofon der Handy-Integration, Übermitteln der Fahrzeugposition via Satellitennavigation sowie schlüsselloses Öffnen und Starten des Fahrzeugs waren möglich. Die Forscher gaben an, relativ leicht einbrechen zu können, weil die Steuergeräte eine sehr große Angriffsfläche boten und kaum durch Standardmaßnahmen geschützt waren. Die Schwachstellen, die diese Untersuchung aufzeigte, fanden sich auffällig oft an Integrationsgrenzen, also an Schnittstellen, an welchen Programmier-Codes unterschiedlicher Implementierer aufeinandertreffen und Annahmen über die Ein- und Ausgabe der jeweils anderen Komponente getroffen werden müssen. Sollte die Installation von Apps durch den Anwender möglich werden, wird die Angriffsfläche noch größer.
Für eine zukünftige I&K-Plattform gibt es aus Sicht der Angriffssicherheit viele architektonische Merkmale zu berücksichtigen. So muss beim Systemstart sichergestellt werden, dass die Hardware noch integer ist. Dazu ließen sich Hardware-Bausteine einsetzen, die Zertifikate in sich tragen, um sich bei anderen Bausteinen authentifizieren zu können und um eine abgesicherte Kommunikation untereinander aufzubauen. Bei versuchter Manipulation sollte sich das System sperren, um somit den Angreifern eine systematische Analyse zu erschweren.
Der Hypervisor, Kernstück der Virtualisierung, wird bei Systemstart in der Regel als erster Software-Baustein geladen und verwaltet die virtuellen Maschinen. Er ist die Komponente mit dem höchsten Vertrauenslevel und muss deshalb in einem hoch-geschützten Baustein abgelegt werden, so dass dessen Integrität durch eine Signatur beim Laden geprüft werden kann.
Die Konfiguration und die Initialisierung virtueller Maschinen und interner Schnittstellen obliegen ebenfalls dem Hypervisor. Die Konfigurationsbeschreibungen deklarieren, wie viele Partitionen erstellt werden, wer welche Hardware und virtuellen Schnittstellen angebunden bekommt und welche Software darin geladen werden soll. Aus Sicherheitsgründen ist die Konfigurationsfunktionalität in einem Modul zu kapseln. Auch die zu ladende Software ist entsprechend abzusichern, damit eine lückenlose Vertrauenskette besteht.
Zur weiteren Absicherung der Plattform kann ein Sicherheitsmonitor dienen, der schädliche Aktivität erkennt und analysiert. Der zukünftige I&K-Domänen-Controller muss nicht nur gründlich auf Sicherheitslücken hin abgesucht werden, sondern auch eine dem Angreifermodell angepasste, gut durchdachte Sicherheitsarchitektur enthalten. Virtualisierung ist dabei ein wertvoller Baustein. Eine optimale Architektur hat ausreichend Code für Funktionalität, bleibt aber gleichzeitig schlank und prägnant, um robust und zertifizierbar zu bleiben.