# IVI (In-Vehicle Infotainment)

> IVI (In-Vehicle Infotainment) ist die Head Unit, die Medien, Navigation, Phone Projection und Konnektivität übernimmt. Moderne Einheiten fahren ein vollständiges Betriebssystem, oft Android Automotive oder embedded Linux, mit Apps, Diensten, Berechtigungen und Netzwerkschnittstellen wie jeder Computer. Das macht die IVI zu einer der größten und am stärksten vernetzten Angriffsflächen im Fahrzeug, und ihre Härtung, offener Debug-Zugang, App-Berechtigungen, lesbare Dateien, ist ein Standard-Testziel.

IVI ist die Head Unit, die Apps, Medien und Konnektivität fährt, oft auf Android oder Linux. Warum sie eine große Angriffsfläche ist und was Härtungschecks suchen.

Source: https://auto-st.com/de/glossar/ivi · Updated: 2026-10-07

## Was ist IVI?

IVI ist die Head Unit im Fahrzeug: der Bildschirm und der Computer dahinter, die Medien, Navigation, Phone Projection, Sprache, App-Stores und die Konnektivität dafür fahren. Frühe Head Units waren Geräte mit fester Funktion. Moderne sind Allzweckcomputer auf einem Automotive-System-on-Chip, mit vollem Betriebssystem, installierbaren Apps, Hintergrunddiensten, einem Berechtigungsmodell und mehreren Funkschnittstellen.

Weil die IVI gleichzeitig mit der Außenwelt und mit den Fahrzeugnetzen spricht, ist sie zugleich exponiert und gut vernetzt, und genau das macht sie für einen Angreifer interessant.

## Wo ist es definiert?

Es gibt keinen einzelnen IVI-Standard. Android-basierte Einheiten folgen der Automotive-Dokumentation des Android Open Source Project und dem Android-Security-Modell (App-Sandboxing, Berechtigungen, SELinux). Linux-basierte Einheiten folgen allgemeiner Linux-Härtungspraxis. Die relevanten Security-Erwartungen kommen aus dem Projekt-Security-Konzept und aus Bedrohungskatalogen wie UN R155 Anhang 5, der Bedrohungen für Backend-Konnektivität, externe Schnittstellen und Fahrzeugdaten listet, die direkt auf die Head Unit zutreffen.

## Was es in der Praxis bedeutet

Ein IVI-Härtungstest sieht sich dasselbe an wie ein Mobile- oder Linux-Review, im Automotive-Kontext: Debug-Zugang, der in Serie zu sein sollte, Apps, die debuggable oder überberechtigt sind, Komponenten, die ohne Schutz an andere Apps exportiert sind, Dateien, die sich vom Gerät ziehen lassen, in Apps eingebackene Secrets und die SELinux- oder Sandbox-Lage.

In Infotainment-Plattformtests sehen wir regelmäßig Serieneinheiten mit aktiviertem ADB, Apps, die debuggable ausgeliefert werden, world-readable System-Properties und Dateien, die Konfiguration oder Credentials preisgeben. Nichts davon ist exotisch; es sind Entwicklungseinstellungen, die es ins ausgelieferte Image geschafft haben.

## Wie AutoST es testet

AutoST verbindet sich über ADB mit einer Android-IVI und fährt einen Härtungstest: Es enumeriert Pakete, gefährliche Berechtigungen, exponierte Komponenten, ziehbare Dateien und die SELinux-Lage und macht eine statische Analyse installierter APKs auf Manifest-Flags wie debuggable Builds und auf fest eingebaute Secrets. Findings werden nach Schweregrad gruppiert, mit Behebung versehen und fließen in denselben Fix Plan wie die UDS- und DoIP-Ergebnisse.

## Häufige Missverständnisse

Die IVI ist nicht harmlos, nur weil sie nicht lenkt oder bremst. Als vernetzter Computer hat sie Pfade zum Rest des Fahrzeugs. Und ein abgeriegeltes Infotainment-OS ist nicht dasselbe wie ein abgesichertes Fahrzeug: Die Gateways und Steuergeräte dahinter brauchen ihren eigenen Test.

## FAQ

**Welche Betriebssysteme fahren IVI-Einheiten?**

Meist Android Automotive OS oder embedded Linux, manchmal QNX, oft mehrere zusammen auf einem SoC mit einem Hypervisor. Phone Projection wie Android Auto und Apple CarPlay läuft darüber als Sitzung vom verbundenen Telefon, nicht als das Betriebssystem der Head Unit selbst.

**Warum ist die IVI ein Security-Thema, wenn sie nicht safety-kritisch ist?**

Die IVI ist eine der am stärksten vernetzten Komponenten im Auto, mit Mobilfunk, WLAN, Bluetooth, USB und App-Stores, und sitzt oft in denselben Netzen wie andere Steuergeräte. Eine Schwäche dort kann ein Einstieg sein, und von der Head Unit aus erreicht ein Angreifer womöglich Gateways und Diagnosepfade, die tiefer ins Fahrzeug führen.

**Ist ein IVI-Test dasselbe wie ein Steuergerätetest über UDS?**

Nein. Ein UDS-Test spricht einen Diagnose-Stack über CAN oder DoIP an. Ein IVI-Härtungstest arbeitet auf Betriebssystemebene, über eine Debug-Schnittstelle wie ADB, und sieht sich Apps, Berechtigungen, Dienste und Dateien an statt Diagnosedienste.

## Sources

- [Android Open Source Project, Automotive-Dokumentation](https://source.android.com/docs/automotive)
- [UN-Regelung Nr. 155, Cyber security and cyber security management system, Anhang 5](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)

## Related

- [Android Automotive OS (AAOS)](https://auto-st.com/de/glossar/android-automotive)
- [ADB (Android Debug Bridge)](https://auto-st.com/de/glossar/adb)
- [SOME/IP (Scalable service-Oriented MiddlewarE over IP)](https://auto-st.com/de/glossar/some-ip)
- [Android-IVI-Security-Checks, die jede Head Unit bestehen sollte](https://auto-st.com/de/insights/android-ivi-security-checks)
- [Der Bildschirm ist auch eine Angriffsfläche.](https://auto-st.com/de/ivi-security-test)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/glossar/ivi