SerDes-basierte Sensoranbindung

Was ein wirksames Schutzkonzept leisten muss

22. Mai 2020, 10:05 Uhr | Von Stefan Lachner und Dr. Lars Völker, Technica Engineering

Fortsetzung des Artikels von Teil 1

Security auf dem Link Layer

Das grundsätzliche Security-Design zielt auf eine Sicherung der Kommunikation pro Link ab; dabei sollen aus Gründen der begrenzten zusätzlichen Rechenleistung für Security symmetrische Schlüssel zum Einsatz kommen.

Das übertragene Datenpaket, der Container, setzt sich im ungesicherten Fall aus einem Header sowie den Nutzdaten zusammen. Für eine Integritätsprüfung und zusätzlich optionale Verschlüsselung der Container-Nutzdaten werden zwei neue Felder in den Container eingefügt: Die acht niederwertigsten Bits eines 64-bit-Security-Counters, um Replay-Attacken zu erkennen, sowie ein Integrity Check Value (ICV), mithilfe dessen die Integrität des Headers, des Counters und der Nutzdaten überprüft werden kann (Bild 1).

Als kryptografisches Verfahren wird AES-GMAC favorisiert, da seine Umsetzung ohne signifikanten Zusatzaufwand auch AES-GCM und somit optionale Verschlüsselung neben dem Integritätsschutz bieten kann.
Das hier vorgestellte Security-Design ist in den Grundlagen bereits abgestimmt und wird aktuell in die Spezifikation überführt, während das folgende Schlüsseltausch-Verfahren sich noch in der Entscheidungsphase innerhalb der Arbeitsgruppe befindet.
Schlüsseltausch auf Basis einer dreistufigen Schlüsselhierarchie
Das aktuelle Konzept zum Schlüsseltausch und zur -verteilung definiert drei Schlüsselhierarchie-Ebenen (Bild 2). Dies erlaubt es, zusätzlich zur eigentlichen Sicherung der Kommunikation auch Teile-Fälschung und -Diebstahl zu verhindern. Die oberste Ebene identifiziert eindeutig ein Steuergerät, die mittlere Ebene bindet Steuergeräte an ein Fahrzeug, und auf der untersten Ebene werden Sitzungsschlüssel bereitgestellt.

Die oberste Ebene der Schlüsselhierarchie nutzt sogenannte Device Keys, die wiederum aus zwei gleich langen Schlüsseln pro Steuergerät gebildet werden: Dem „Tier-1 Device Key“ und dem „OEM Device Key“. Der Tier-1 Device Key wird durch den Tier-1 bei der Fertigung des Steuergeräts persistent eingebrannt und hiermit dem Steuergerät in Kombination mit einer eindeutigen Identifikationsnummer des Halbleiters eine eindeutige, gesicherte Identität gegeben. Diese kann für weitere Prozesse dem OEM bekanntgegeben werden. Die zweite Schlüsselkomponente wird vom jeweiligen OEM bei der Produktion des Fahrzeugs im Werk geschrieben, wodurch das Bauteil nun an den OEM gebunden ist und dieser die Kontrolle und Verantwortung über das Steuergerät übernimmt.

Durch den Einsatz von Tier-1 und OEM Device Keys ist sichergestellt, dass produzierte Steuergeräte auch bereits in der Logistik immer kryptografisch gesicherte Identitäten besitzen. Im Werk des OEM oder beim Service-Tausch der Komponente können damit einfach Teile-Fälschungen erkannt und verhindert werden. Der vollständige Gesamtprozess hierfür ist nicht Teil des ASA-Standards und kann vom OEM basierend auf dem ASA-Standard gestaltet werden.

Innerhalb der Steuergeräte ist die primäre Nutzung der Device Keys die Installation von Binding Keys der nächsten Ebene. Der hierfür notwendige vollständige Device Key ergibt sich aus einer XOR-Operation des Tier-1 Device Keys und des OEM Device Keys. Der vollständige Device Key ist ausschließlich dem OEM bekannt, während der Tier-1 nur Kenntnis über die von ihm geschriebenen Device Keys hat. Hiermit ist sichergestellt, dass die Kontrolle auf den OEM übergehen kann.
Der Binding Key der mittleren Schlüsselhierachieebene sorgt für die persistente Bindung eines Bauteils an ein Fahrzeug bzw. an ein übergeordnetes Steuergerät im Fahrzeug, hier Root ECU genannt. Hierdurch wird verhindert, dass gestohlene Teile wie beispielsweise Kameras oder Sensoren in einem anderen Fahrzeug funktionsfähig sind. Jede ASA ECU erhält einen eigenen Binding Key, der im Back End des OEM erzeugt und mittels der passenden Device Keys verschlüsselt an die Steuergeräte übertragen wird. Die persistente Installation des Binding Keys kann sowohl im Werk bei der Produktion des Fahrzeuges als auch im Service bei einem etwaigen Teile-Tausch erfolgen. Jede ASA ECU hat ausschließlich Kenntnis über den eigenen Binding Key, wohingegen die Root ECU alle ihr zugehörigen Binding Keys kennen muss.

Die Sicherung der Kommunikation im Betrieb wird durch den Link Key sichergestellt, der die dritte Schlüsselhierarchie-Ebene darstellt. Jeder zu sichernde ASA-Link verfügt über einen eigenen Link Key, der bei jedem Lifecycle des Fahrzeugs erneuert wird. Die Erzeugung aller Link Keys für die ASA-Links und deren Verteilung erfolgt dabei durch die Root ECU selbst. Die Verteilung der Link Keys zu den beiden ASA-Devices dieses Links geschieht verschlüsselt. Diese Schlüssel werden mit dem jeweiligen Binding Key des ASA-Devices geschützt.

Insgesamt zeigt sich ein deutlicher Vorteil des Konzeptes: Kleinere, mit wenig Rechenleistungs-Überschuss ausgestattete Steuergeräte müssen lediglich einfache, symmetrische Kryptografie-Operationen durchführen, wohingegen die Hauptlast wie die schnelle und sichere Erzeugung und Verteilung von vielen Schlüsseln durch ein leistungsstarkes Steuergerät, die Root ECU, getragen wird. Zudem kann auf asymmetrische Kryptografie innerhalb der ASA ECUs verzichtet werden.
Im Rahmen des autonomen Fahrens wird es entscheidend sein, dass das Gesamtsystem Safety- und Security-Anforderungen umsetzt.

Die aktuell bestehenden Security-Anforderungen bei der Anbindung von (außenliegenden) Sensoren können bei Ethernet-basierter Anbindung mittels MACsec erfüllt werden. Aber beim Einsatz anderer Technologien (z.B. SerDes-basierter Kameralinks) gilt es diese Lücke noch zu schließen. Die Automotive SerDes Alliance hat diesen Bedarf erkannt und eine passende Arbeitsgruppe initiiert, in welcher die oben genannten Konzepte aktuell in den Standard integriert werden.

Anbieter zum Thema

zu Matchmaker+
Technica Engineering
Bild 2. Darstellung der Schlüsselhierarchie am Beispiel der Verteilung von Link-Keys an die Steuergeräte.
© Technica Engineering

  1. Was ein wirksames Schutzkonzept leisten muss
  2. Security auf dem Link Layer

Verwandte Artikel

elektroniknet