Auf dieser Seite wird beschrieben, wie Sie Startfunktionen für die fahrzeugbasierte Bindungsverschlüsselung aktivieren.
Übersicht
Das Hauptziel der Startfunktion für Fahrzeugbindungen besteht darin, Daten im Infotainmentsystem des Fahrzeugs vor der Entfernung aus dem Fahrzeug zu schützen. Dies ist indem der Speicherverschlüsselungsschlüssel an eine andere elektronische Steuereinheit (Electronic Control Unit, ECU) gebunden wird. Das IVI wird entfernt und in einem anderen Fahrzeug (oder auf einer Testbank) platziert, verschlüsselte Nutzerdaten werden auf dem IVI kann nicht entschlüsselt werden.
Zum Binden von Dateiverschlüsselungsschlüsseln fügt Vold einen fahrzeugspezifischen Seed mit Schlüsselverschlüsselung ein
Schlüsselableitung, damit die Schlüssel eindeutig und physisch an das Fahrzeug gebunden sind. Der Seed ist ein Byte-Array,
vom OEM als neue VHAL-Eigenschaft der Fahrzeughardware-Abstraktionsschicht offengelegt wird,
STORAGE_ENCRYPTION_BINDING_SEED Die Berechtigungen dieser Property sind eingeschränkt,
nur von privilegierten System-Daemons abgefragt werden.
Architekturdiagramm
Diese Abbildung veranschaulicht die Architektur der fahrzeuggebundenen Integration:
Abbildung 1: Fahrzeuggebundene Architektur.
Fahrzeugbasierte Bindung aktivieren
Die Bindung der Speicherverschlüsselung an das Fahrzeug muss explizit aktiviert werden und kann nicht aktiviert werden oder deaktiviert werden, ohne das Gerät auf die Werkseinstellungen zurückzusetzen. Das bedeutet, dass eine OTA-Aktualisierung die Funktion zu aktivieren, ohne dabei die Gerätedaten zu löschen. Ein OEM könnte die Funktion nach wenn das Gerät auch auf die Werkseinstellungen zurückgesetzt wird. beispielsweise bei einem Dienstbesuch.
Diese Funktion wird durch Unterstützung der Property STORAGE_ENCRYPTION_BINDING_SEED aktiviert
im vom Anbieter bereitgestellten Fahrzeug-HAL. Diese Eigenschaft enthält einen Byte-String mit einer Länge von 16 Byte und ist
wird voraussichtlich in einer vom IVI getrennten ECU beibehalten. Die Eigenschaft wird anfangs vom
Android Automotive OS (AAOS), das sie mithilfe einer kryptografisch sicheren Zufallszahl generiert
Generator (CSRNG) erstellt. AAOS liest die Eigenschaft dann bei nachfolgenden Startvorgängen.
Wie der VHAL den Wert von STORAGE_ENCRYPTION_BINDING_SEED speichert, ist anbieterspezifisch.
Allgemeine Empfehlungen zum Schutz des Samens:
- (Empfohlen) Seed wird von einer ECU im Fahrzeug gespeichert, das sich physisch gut geschützt sind. Falls nicht, ist es einfach, sowohl das IVI als auch die ECU aus dem Fahrzeug.
- (Empfohlen) IVI und ECU sollten sich gegenseitig authentifizieren, um den Seed an um Spoofing-Anfragen für den Seed-Wert von der ECU zu verhindern.
- (Empfohlen) Der Seed-Wert sollte zum Schutz vor CAN-Busschnüffler.
Fügen Sie außerdem Folgendes hinzu, damit der Anbieter init.target.rc
late-fs vor mount_all --late:
# feed vehicle binding seed to vold exec_start vold_seed_binding
Der Fahrzeug-HAL sollte in early_hal und nicht in hal now gestartet werden.
Auf persist.*-Systemattribute kann in early-hal nicht zugegriffen werden, da die
Partition /data wurde noch nicht bereitgestellt.
Fahrzeugbasierte Bindung konfigurieren
Wenn der Seed der ECU nicht übereinstimmt, startet das Gerät im Rahmen der Wiederherstellung neu und fordert den Nutzer auf, die Daten zu löschen.
die Partition /data ein oder versuchen Sie es noch einmal.
Das Verhalten von Aufforderungen und Datenlöschungen kann geändert werden in builtins.cpp:
- Ändern Sie
prompt_and_wipe_datazuwipe_data. Die Gerätedaten werden gelöscht und und startet dann ohne Eingabeaufforderung neu. - Die Prompt-Nachricht befindet sich in
recovery.cpp.
Abbildung 2: Prompt-Nachricht.
Fahrzeugbasierte Bindung testen
Simulierte Tests
In der Tabelle mit den
packages/services/Car/cpp/security/vehicle_binding_util/tests
So führen Sie diesen Beispieltest aus:
attest libvehicle_binding_util_test
Integrationstests
Ein Atest-Test wird in
packages/services/Car/cpp/security/vehicle_binding_util/tests
So führen Sie diesen Integrationstest aus:
atest vehicle_binding_integration_test