DE102009002396A1 - Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu - Google Patents

Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu Download PDF

Info

Publication number
DE102009002396A1
DE102009002396A1 DE102009002396A DE102009002396A DE102009002396A1 DE 102009002396 A1 DE102009002396 A1 DE 102009002396A1 DE 102009002396 A DE102009002396 A DE 102009002396A DE 102009002396 A DE102009002396 A DE 102009002396A DE 102009002396 A1 DE102009002396 A1 DE 102009002396A1
Authority
DE
Germany
Prior art keywords
sensor
authentication
mac
bit
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102009002396A
Other languages
English (en)
Inventor
Torsten Schuetze
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102009002396A priority Critical patent/DE102009002396A1/de
Priority to US12/760,718 priority patent/US8639925B2/en
Publication of DE102009002396A1 publication Critical patent/DE102009002396A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60C—VEHICLE TYRES; TYRE INFLATION; TYRE CHANGING; CONNECTING VALVES TO INFLATABLE ELASTIC BODIES IN GENERAL; DEVICES OR ARRANGEMENTS RELATED TO TYRES
    • B60C23/00—Devices for measuring, signalling, controlling, or distributing tyre pressure or temperature, specially adapted for mounting on vehicles; Arrangement of tyre inflating devices on vehicles, e.g. of pumps or of tanks; Tyre cooling arrangements
    • B60C23/02—Signalling devices actuated by tyre pressure
    • B60C23/04—Signalling devices actuated by tyre pressure mounted on the wheel or tyre
    • B60C23/0408—Signalling devices actuated by tyre pressure mounted on the wheel or tyre transmitting the signals by non-mechanical means from the wheel or tyre to a vehicle body mounted receiver
    • B60C23/0422—Signalling devices actuated by tyre pressure mounted on the wheel or tyre transmitting the signals by non-mechanical means from the wheel or tyre to a vehicle body mounted receiver characterised by the type of signal transmission means
    • B60C23/0433—Radio signals
    • B60C23/0447—Wheel or tyre mounted circuits
    • B60C23/0455—Transmission control of wireless signals
    • B60C23/0462—Structure of transmission protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/002—Countermeasures against attacks on cryptographic mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/20—Manipulating the length of blocks of bits, e.g. padding or block truncation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Mechanical Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zu einem Manipulationsschutz eines Sensors und von Sensordaten des Sensors sowie einen Sensor hierfür, wobei im Rahmen der Authentifizierung eine Zufallszahl (R) von einem Steuergerät an den Sensor geschickt wird, wobei zur Erkennung einer Manipulation der Sensordaten die Sensordaten von dem Sensor zu dem Steuergerät mit einem kryptographischen Integritätsschutz versehen werden und wobei zu einer Verhinderung von Replay-Attacken den Sensordaten zusätzliche zeitvariante Parameter (R) hinzugefügt werden, welche die Sensordaten mit dem Integritätsschutz und den hinzugefügten zeitvarianten Parametern (R) von dem Sensor an das Steuergerät schicken werden. Dabei wird für die zeitvarianten Parameter (R) nach der Authentifizierung des Sensors die Zufallszahl (R) oder ein Teil der Zufallszahl (R) oder eine durch eine Funktion aus der Zufallszahl (R) gewonnene Zahl herangezogen.

Description

  • Stand der Technik
  • Die vorliegende Erfindung betrifft ein Verfahren zu einem Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu.
  • Bei modernen Motoren ist ein Raildruck, welcher von einem Druckregelventil eingeregelt und von einem Raildrucksensor überwacht wird, ein wichtiger Parameter zur Beeinflussung und/oder Regelung der Leistung des Motors. Bisher wurden Raildrucksensoren RDS mit einem analogen Interface eingesetzt. Die Daten der RDS-Sensoren waren in der Vergangenheit ein beliebtes Ziel von Manipulationen, so genannte Tuningangriffe. Zwei wesentliche Angriffsszenarien sind:
    • 1. Austausch des RDS-Sensors durch ein ähnliches Modell mit anderen Kennlinieneigenschaften.
    • 2. Manipulation der analogen Druckdaten auf der Übertragungsstrecke, etwa durch Einfügen eines Widerstandes (→ niedrigere Spannung → vorgespiegelter niedrigerer Druck).
  • Zukünftige Raildrucksensoren können vorzugsweise mit einer digitalen PSI5-Schnittstelle ausgestattet werden. In diesem Zusammenhang lautet eine wesentliche Anforderung, dass eine unbestreitbar belastbare Aussage möglich sein soll, ob manipuliert wurde.

    Das Schutzziel 1 (Verhindern des Austausch des Sensors) lässt sich durch eine sog. Authentifizierung des Sensors beim Steuergerät erreichen. Hierfür werden z. B. Challenge-Response-Protkolle verwendet. Im Stand der Technik werden für die Authentifizierung oft unilaterale Authentifizierungsverfahren nach „ISO/IEC 9798-2, Information technology-Security Techniques-Entity Authentication – Part 2 Mechanisms using symmetric encipherment algorithms". ISO/IEC, 1999 verwendet, entweder als Zwei-Pass Protokoll mit Zufallszahlen (two-pass unilateral authentication protocol with nonces) oder als Ein-Pass-Protokoll mit Zeitstempeln oder Sequencenummern (one-pass unilateral authentication protocol with time stamps/sequence counters).

    Das Schutzziel 2 (Erkennung von Manipulationen der Sensordaten) lässt sich durch Integritätsschutzverfahren erreichen. Im Stand der Technik werden für den Integritätsschutz der Daten standardisierte kryptographische Verfahren, etwa Message Authentication Codes oder digitale Signaturen verwenden, z. B. „ISO/IEC 9797-1. Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher. ISO/IEC, 1999 oder ISO/IEC 9797-2. Information technology – Security techniques – Message Authentication Codes (MACs) – Part 2: Mechanisms using a dedicated hash-function. ISO/IEC, 2002”.
  • Zur Verhinderung von Replay-Attacken werden darüber hinaus nach Stand der Technik den per Integritätsschutz zu sichernden Daten zusätzliche sog. zeitvarianten Parametern (Zufallszahlen, Time Stamps/Zeitstempel, Sequence Numbers/Sequenzzahlen) eingefügt.
  • Offenbarung der Erfindung
  • Vorteile der Erfindung
  • Das erfindungsgemäße Verfahren, bzw. der erfindungsgemäße Sensor, ermöglichen es, Standardverfahren zur Authentifizierung eines Sensors und Standardverfahren zu einer Transaktionsauthentifizierung von Sensordaten des Sensors, wobei die Sensordaten zwischen dem Sensor und einem Steuergerät übertragen werden, miteinander zu verknüpfen, indem Zufallsdaten aus dem Authentifizierungsverfahren für eine Darstellung der zeitvarianten Parameter des Transakti onsauthentifizierungsverfahrens herangezogen werden. Man erreicht dadurch eine enge kryptographische Kopplung von Authentifizierung und Transaktionsauthentifizierung, was einen deutlichen Sicherheitsvorteil des erfindungsgemäßen Verfahrens ausmacht. Weiterhin spart man gleichzeitig noch die Implementierung eines Zufallszahlengenerators auf der Sensorseite ein, da der oft standardmäßig in Steuergeräten vorhandene Zufallsgenerator für alle Verfahrensschritte ausreicht. Damit ergibt sich insgesamt ein extrem sicheres Verfahren zur Sensorauthentifizierung und zur Transaktionsauthentifizierung von Sensordaten bei reduziertem technischen Aufwand.
  • Weitere Vorteile und Verbesserungen ergeben sich durch die Merkmale der abhängigen Ansprüche.
  • In einer vorteilhaften Ausgestaltung werden die zeitvarianten Parameter in jedem Schritt der Transaktionauthentifizierung verändert. Dieser Vorgang entspricht einem Sequenzzähler und ermöglicht eine besonders enge kryptographische Kopplung der Verfahrensteile Authentifizierung und Transaktionsauthentifizierung, und damit einen weiteren Sicherheitsgewinn. Besonders vorteilhaft, weil besonders einfach umsetzbar, ist, wenn die Veränderung der zeitvarianten Parameter einer schrittweisen Inkrementierung entspricht.
  • In einem bevorzugten Ausführungsbeispiel wird als Authentifizierungsverfahren ein Challenge-Response-Verfahren herangezogen, welches sich durch besonders hohe Sicherheit auszeichnet. Weiterhin vorteilhaft ist eine Verwendung von MAC-Verfahren zum Integritätsschutz der Sensordaten, welche ebenfalls hohen Sicherheitsstandards genügen, wobei besonders zweckmäßig die extrem sicheren Verfahren EMAC und OMAC sind.
  • In besonderen Ausgestaltungsformen sind die zeitvarianten Parameter entweder als Zeitstempel, Sequenzzähler oder als Zufallszahlen ausgestaltet. Diese Ausgestaltungen bringen vor allem den Vorteil einer besonders einfachen, aber doch zweckmäßigen Umsetzung des erfindungsgemäßen Verfahrens mit sich.
  • Zeichnungen
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Die Zeichnungen sind lediglich beispielhaft und schränken den allgemeinen Erfindungsgedanken nicht ein. Gleiche oder gleich wirkende Teile sind mit gleichen Bezugszeichen versehen.
  • Es zeigen:
  • 1 eine schematische Darstellung eines Systems zur Authentifizierung eines Sensors A bei einem Steuergerät B mittels eines Challenge-Response-Verfahrens,
  • 2 eine schematische Darstellung eines Systems zum Integritätsschutz der Sensordaten,
  • 3 eine schematische Darstellung eines Systems zur Authentifizierung eines Sensors A bei einem Steuergerät B,
  • 4 eine schematische Darstellung zur Erläuterung einer Reflektionsattacke bei einfacher Authentifizierung,
  • 5 eine schematische Darstellung zur Erläuterung eines Integritätsschutz der Sensordaten durch Message Authentication Codes EMAC oder CMAC, und
  • 6A, 6B eine schematische Darstellung zur Erläuterung eines Gesamtprotokolls einer erfindungsgemäßen Verbindung Authentifizierung und Integritätsschutz, bzw. Authentifizierung und Transaktionsauthentifizierung, zur Transaktionssicherheit der Sensordaten.
  • Im Folgenden wird zur Beschreibung der Erfindung wo zweckmäßig auf das Beispiel eines RDS-Sensors und eines Steuergeräts in einem Kraftfahrzeug zurückgegriffen. Dies stellt aber keine Einschränkung der Erfindung auf dieses Beispiel dar, da das beschriebene Sicherheitsgesamtkonzept allgemein für die Sicherheitsgewährleistung der Kommunikation zwischen einem beliebigen Steuergerät und einem Sensor konzipiert ist.
  • 1 zeigt eine schematische Darstellung eines Systems zur Authentifizierung eines Sensors A bei einem Steuergerät B mittels eines Challenge-Response-Verfahrens. Dabei sendet das Steuergerät B eine Anforderung, ”Challenge” an den Sensor B, welcher zur Authentifizierung mit einer Antwort ”Response” antwortet. Hierbei wird ein konkretes Verfahren schematisch angezeigt, welches Teil eines übergreifenden Sicherheitskonzeptes ist, welches hohe Sicherheitsanforderungen erfüllt und Angriffe der oben aufgezeigten Typen sowie weitere Sicherheitsbedrohungen und -verletzungen kryptographisch sicher erkennt.
  • Es handelt sich in einem ersten Schritt um ein Challenge-Response-Verfahren zur Authentifizierung des RDS-Sensors beim Steuergerät ECU. Ziel der Authentifizierung ist es, festzustellen, ob zum Zeitpunkt der Authentifizierung der RDS über ein gültiges Authentifizierungsmerkmal, dh Kenntnis eines kryptographischen Schlüssels, verfügt, und dieses Merkmal fest an seine Identität, beispielsweise eine Seriennummer, zu binden (Stichpunkte Freshness, Liveliness of Key). In der 1 ist diese Authentifizierung mittels des Challenge-Response-Verfahrens schematisch angezeigt.
  • 2 zeigt eine schematische Darstellung eines Systems zum Integritätsschutz der Sensordaten. In diesem zweiten Schritt des Sicherheitskonzepts werden dabei nach der Authentifizierung – dh der Empfänger der Daten, nämlich das Steuergerät (ECU) B, weiß, dass es mit einem authentifizierten Sender, nämlich dem RDS-Sensor A, kommuniziert – die übertragenen Daten fortlaufend mit einem Integritätsschutz, vorzugsweise mit zeitvarianten Parametern wie Zufallszahlen, Sequenzzahlen (Sequenzzähler) oder Zeitstempeln, versehen. Dies ist in 2 durch Anhängen eines ”Tag” an die von Sensor A zu Steuergerät B gesendeten Daten dargestellt, wobei der ”Tag” die zeitvarianten Parameter repräsentiert. Diese zeitvarianten Parameter werden nach der Verarbeitung der Druckdaten kryptographisch geprüft und eine Manipulation der RDS-Daten wird kryptographisch sicher erkannt, dh es treten keine zusätzlichen Latenzzeiten in der Echtzeitdatenverarbeitung durch die Kryptographie auf und Manipulationen können somit detektiert werden.
  • Als effizientes Verfahren zur Erreichung des kryptographischen Integritätsschutzes werden sg Message Authentication Codes MAC vorgeschlagen. Bei den so genannten CBC-MAC-Verfahren werden zwei weitere kryptographische Schlüssel benutzt, in einem weiteren modifizierten Vorschlag, dem so genannten OMAC, kommt man sogar mit nur einem zusätzlichen Integritätsschlüssel aus. Als Realisierungsoption für den RDS-Sensor mit dem digitalem PSI5-Interface werden konkret vorgeschlagen: EMAC sowie CMAC, bekannt auch als OMAC. Beide Verfahren benutzen eine symmetrische Blockchiffre, vorgeschlagen wird entweder der AES-128, siehe ”FIPS 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, November 2001, http://csrc.nist.gov/”, Schlüssellänge k = 128 bit, Blockbreite n = 128 bit, oder alternativ PRESENT, siehe ”A. Bogdanov, L. R. Knudsen, G. Leander, C. Paar, A. Poschmann, M. J. B. Robshaw, Y. Seurin, and C. Vikkelsoe, PRESENT: An ultra-lightweight block cipher, in P. Pallier and I. Verbauwhede, editors, Proceedings of CHES 2007, volume 4727 of Lecture Notes in Computer Science, Seiten 450–467, Springer-Verlag, 2007”, Schlüssellänge k = 128, Blockbreite n = 64. PRESENT ist noch eine relativ neue Blockchiffre, sie ist bei weitem nicht so ausgereift wie AES, inzwischen gibt es auch erste Berichte über theoretische Kryptoanalyse-Angriffe.
  • In einem dritten Schritt des Sicherheitskonzepts werden zur Verhinderung von so genannten Replay-Attacken zusätzlich zu den Nutzdaten, dh Druckwerten, Zufallszahlen in die per Integritätsschutz abzusichernden Daten eingefügt. Diese Zufallszahlen werden im Klartext an die ECU übertragen und mittels MAC mit verifiziert.
  • Um eine feste Bindung der Authentifizierung und des Integritätsschutzes zu erhalten, wird in einem vierten, entscheidenden, Schritt des vorgestellten Sicherheitskonzepts vorgeschlagen, die Zufallszahlen beider Schritte, bzw. wie unten erläutert die zeitvarianten Parameter und die Zufallszahlen der beiden Schritte, zu verbinden. Dadurch erreicht man eine so genannte Transaktionsauthentifizierung. Man erreicht durch diese Verbindung der beiden Teilschritte Authentifizierung und Integritätsschutz (damit dann auch Transaktionsauthentifizierung) eine enge kryptographische Kopplung beider Teile und spart gleichzeitig noch die Implementierung eines Zufallszahlengenerators auf der Sensorseite ein.
  • Die Authentifizierung sollte zeitnah nach einem Motorstart erfolgen, dh in den ersten Minuten. Es ist jedoch nicht notwendig, sie direkt in der Startup-Phase durchzuführen. Der Integritätsschutz erfolgt erst nach der Authentifizierung, vorher ergibt dieser Integritätsschutz kryptographisch keinen Sinn. Während die Authentifizierung relativ selten, mindestens nach jedem Motorstart und nach Verlust mehrerer Pakete bzw. der Synchronität, stattfindet, werden die Druckdaten fortlaufend mit einem Integritätstag versehen, dh beispielsweise alle t = 16 Blöcke. Die während der Authentifizierung von ECU zu Sensor übertragene Zufallszahl kann zur Verbindung der Verfahrensschritte z. B. als Bestandteil beim Integritätsschutz als Sequence Counter benutzt und mit jedem (t = 16) × (n = 128) bit Block inkrementiert werden.
  • Falls der Integritätsschutz standardmässig bei jedem Druckpaket verwendet wird, sollten vor der Authentifizierung entweder die MAC-Daten ignoriert werden, was ungünstig ist, oder mit den auf dem RDS-Sensor vorhandenen Zufallszahlen benutzt werden. Nach der erfolgten Authentifizierung wird der ausgehandelte Sequence Counter verwendet.
  • Im Folgenden wird das Verfahren zur erfindungsgemäßen Transaktionsauthentifizierung an einem Ausführungsbeispiel detailliert beschrieben. Während die dabei zuerst vorgestellten Schritte 1–3 des Sicherheitskonzepts teilweise aus dem Stand der Technik aus anderen Anwendungsgebieten bekannt sind, ergibt sich der entscheidende vierte Schritt des erfindungsgemäßen Sicherheitskonzepts, welcher am Ende der detaillierten Beschreibung u. a. anhand von 6 erläutert wird, aus einer Verknüpfung der vorherigen Verfahrensschritte.
  • Die kryptographischen Sicherheitsziele Authentizität des Senders und der Daten, Integrität der Daten sowie Freshness der kryptographischen Schlüssel und Daten und Verhinderung von Replay-Attacken werden mittels folgender Mechanismen erreicht:
    Authentifizierung mittels Challenge-Response-Verfahren (Verschlüsselung einer Challenge nebst Identität); Integritätsschutz mittels Message Authentication Codes basierend auf dem CBC-Modus nebst entsprechendem Padding und MAC-Strengthening, dh EMAC und CMAC; Verhinderung von Replay-Attacken durch Einfügen von Zufallszahlen nebst den reinen Nutzdaten; Sichere kryptographische Bindung beider Protokollteile durch Verwendung eines Teils der Challenge als Sequence Counter für den Integritätsschutz; Für alle Mechanismen wird lediglich ein einziger Grundbaustein, eine symmetrische Blockchiffre, benötigt – als Realisierungsoption wird konkret AES-128 oder alternativ PRESENT vorgeschlagen; Weiterhin wird wegen der Verbindung der beiden Protokollteile lediglich auf dem Steuergerät ein Zufallszahlengenerator benötigt.
  • Seien A der RDS-Sensor und B das Steuergerät ECU. Ziel ist die Authentifizierung von A gegenüber B, dh A weist B nach, dass er über ein gemeinsames Geheimnis, einen kryptographischen Schlüssel, zum Zeitpunkt der Authentifizierung verfügt. Beide Teilnehmer an dem Protokoll verfügen über drei gemeinsame Schlüssel:
    KAB,Auth – gemeinsamer Authentifizierungsschlüssel
    KAB,MAC1 – gemeinsamer Message Authentication Code Schlüssel 1
    KAB,MAC2 – gemeinsamer Message Authentication Code Schlüssel 2
  • Im Fall des CMAC-Algorithmus genügt ein gemeinsamer Message Authentication Code Schlüssel 1, KAB,MAC1. Sei EncK ein Verschlüsselungsalgorithmus mit Schlüssel K der Länge k und der Blockbreite n, etwa EncK = AES, k = length(K) = 128, n = 128. Alternativ käme beispielsweise EncK = PRESENT, k = length(K) = 128, n = 64 in Betracht. Weiterhin seien IDA und IDB systemweit eindeutige Identitäten der Teilnehmer, etwa 32 bit lange Seriennummern bzw. Typteilenummern. Die Länge der Seriennummern ist kryptographisch nicht bedeutsam. Wichtig ist, dass alle Teilnehmer im Gesamtsystem, d. h. nicht nur ein Motor/Fahrzeug, eindeutig identifiziert werden können. Dies spielt beim Key Management, wie später beschrieben, eine zentrale Rolle.
  • Seien weiterhin in diesem Beispiel RA bzw. RB von A bzw. B generierte Zufallszahlen, deren zweckmäßige Länge später spezifiziert wird.
  • Im Folgenden wird eine beispielhafte Authentifizierung des Sensors A gegenüber dem Steuergerät B beschrieben. Die Schritte 1–3 sind dabei schematisch in 3 dargestellt.
    • 1. B generiert eine 64 bit Zufallszahl RB
    • 2. B sendet diese Zufallszahl RB zusammen mit seiner Identität IDB an A: B → A: RB||IDB (64 bit||32 bit)
    • 3. A verschlüsselt die Nachricht RB||IDB, dh EncKAB,Auth(RB||IDB) und schickt dies zusammen mit IDA an B zurück: A → B: EncKAB,Auth(RB||IDB)||IDA (128 bit||32 bit)
    • 4. B kann sofort nach Abschluss des Protokollschrittes in 2. damit beginnen, seinerseits den Response y = EncKAB,Auth(RB||IDB) zu berechnen. Nach Erhalt der Antwort y' in 3. vergleicht er y mit der übermittelten Antwort y': gilt: y = y' = EncKAB,Auth(RB||IDB)?
  • Er vergleicht weiterhin die Identität von A mit der gewünschten, dh gilt: IDA = ID'A?
  • Nur im Fall, dass beide Vergleiche erfolgreich sind, hat sich A gegenüber B erfolgreich authentifiziert.
  • Im Folgenden wird eine zweckmäßige Modifikation der Schritte 3. und 4. beschrieben. Um Kommunikationsbandbreite einzusparen, werden im Schritt 3 nur die höchstwertigen 64 bit der Verschlüsselung übertragen und demzufolge auch in 4. verglichen. Dies ist nicht gleichbedeutend mit der Anwendung eines Verschlüsselungsverfahrens mit 64 bit Blockbreite.
    • 3'. A → B: msb127,...,64[EncKAB,Auth(RB||IDB)]||IDA (64 bit||32 bit)
  • Im Folgenden wird das Gesamtverfahrens zur Authentifizierung 1 dargestellt.
    • 1. B generiert eine 64 bit Zufallszahl RB
    • 2. B sendet diese Zufallszahl RB zusammen mit seiner Identität IDB an A: B → A: RB||IDB (64 bit||32 bit)
    • 3. A verschlüsselt die Nachricht RB||IDB, dh EncKAB,Auth(RB||IDB) und schickt die 64 most significant bits (höchstwertige Bits) zusammen mit IDA an B zurück A → B: msb127,...,64[EncKAB,Auth(RB||IDB)]||IDA (64 bit||32 bit)
    • 4. B kann sofort nach Abschluss des Protokollschrittes in 2. damit beginnen, seinerseits den Response y = msb127,...,64[EncKAB,Auth(RB||IDB)] zu berechnen. Nach Erhalt der Antwort y' in 3. vergleicht er y mit der übermittelten Antwort y': gilt: y = y' = msb127,...,64[EncKAB,Auth(RB||IDB)]?
  • Er vergleicht weiterhin die Identität von A mit der gewünschten, dh gilt: IDA = ID'A?
  • Nur im Fall, dass beide Vergleiche erfolgreich sind, hat sich A gegenüber B erfolgreich authentifiziert.
  • Hierzu gilt es folgendes zu bemerken.
    • (i) Bei dem hier vorgeschlagenen Schritt des Sicherheitskonzepts handelt es sich im Wesentlichen um das ISO/IEC 9798-2 two-pass unilateral authentication protocol. Siehe hierzu ”ISO/IEC 9798-2, Information technology – Security techniques – Entity Authentication – Part 2: Mechanisms using symmetric encipherment. algorithms ISO/IEC, 1994”. Dies gilt bis auf die Modifikation der Übertragung lediglich der 64 most sigificant bits von Enc.
    • (ii) Zur Verhinderung von Replay-Attacken, dh Aufzeichnung des gesamten Verkehrs und Wiedereinspielen in späteren Protokollabläufen, wird die Zufallszahl RB im Protokoll verwendet. Kryptographisch muss es sich um eine ”nonce = number used only once” handeln. Um Replay-Attacken bei der Authentifizierung zu verhindern, wird in dem betrachteten Anwendungsszenario eine Länge von 64 bit als ausreichend angesehen. Kürzere zeitvariante Parameter führten in der Vergangenheit, beispielsweise WEP-Encryption bei WLAN 802.11b, KeeLoq, bereits zu Angriffen und/oder ausnutzbaren Schwächen des Verfahrens. Weitere Ausführungen zur Notwendigkeit der Authentifizierung und alternative Möglichkeiten finden sich im Folgenden. Für die Erzeugung der Zufallszahlen im Steuergerät B wird ein Zufallszahlengenerator RNG benötigt. Dieser sollte die Eigenschaft K3 hoch bei deterministischen RNGs haben. Siehe hierzu ”Bundesamt für Sicherheit in der Informationstechnik BSI, AIS 20: Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Anwendungshinweise und Interpretationen zum Schema (AIS) Version 1, 2.12.1999, BSI, 2001, nachzulesen unter http://www.bsi.bund.de/zertifiz/zert/interpr/ais20.pdf”.
  • Mindestens sollte er die Eigenschaft P1 hoch bei physikalischen RNGs, besser P2 hoch, haben. Siehe hierzu „Bundesamt für Sicherheit in der Informationstechnik BSI, AIS 31: Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Anwendungshinweise und Interpretationen zum Schema (AIS) Version 1, 25.9.2001, BSI, 2001, nachzulesen unter „http://www.bsi.bund.de/zertifiz/zert/interpr/ais3i.pdf”. Siehe hierzu auch „W. Killmann and W. Schindler, Ein Vorschlag zu: Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Technisches Papierzu AIS 31, Version 3.1, 25.9.2001, BSI, 2001, nachzulesen unter http://www.bsi.bund.de/zertifiz/zert/interpr/trngkr31.pdf”.
    • (iii) Die beispielhafte Wahl von |RB| = 64 führt zu einer Angriffskomplexität von 233 = 264/2+1 Kommunikationssessions beim gleichzeitigen Abspeichern von 264/2 × 232 Paaren (RB||msb127...0EncK(RB)) (64 bit||64 bit) für einen simplen Zwei-Schritt Wörterbuch-Angriff. Siehe hierzu beispielsweise ”Andrey Bogdanov and Christof Paar, On the Security and Efficiency of Real-World Lightweight Authentication Protocols, In Secure Component and System Identification, März 2007, Workshop Record of SECSI, Berlin, März 17–18, 2008”. Man beachte, dass in dem Einsatzszenario RDS-Sensor die Kommunikation zum Sender hin (Challenge) um Größenordnungen langsamer ist als die Kommunikation vom Sender zum Steuergerät (Response). Das simple Raten der 64 bit Response msb127...0EncK(RB) hat eine Angriffskomplexität von 264-1 = 263. Die Identitäten IDA, IDB werden in dem System benötigt, da später auch ein Einsatz mehrer Sensoren geplant ist. Sie sind z. B. als 32 bit Werte angenommen, können jedoch ohne größere Probleme auch 64 bit lang sein. Sollten die Datenpakete RB||IDB, etwa durch Wahl einer 80 bit ID, länger als 128 bit werden, so ist zu beachten, dass dann für EncK(RB||IDB) ein sicherer Mode of Operation (Ausführungs-Modus) verwendet wird, etwa CBC-Encryption with random IV and padding, nicht mehr der simple ECB-Mode, dh die Lösung ist prinzipiell machbar, aber teurer.
  • Ein aus Sicht der Kryptographie besserer Wert für die Länge der Challenge wäre etwa |RB| = 128. Dann hätten sowohl eine Scan-Attacke (Raten der Response) als auch Wörterbuch-Attacke eine Angriffskomplexität von ca. 264. Allerdings hätten dann die Nachrichtenblöcke die Grenze von 128 bit überschritten, kürzere Identifier ID sind aber nicht möglich.
    • (iv) Das vorgeschlagene Verfahren verhindert wirksam so genannte ”Reflection Attacks”, manchmal auch ”Impersonation” oder ”Parallel Sessions Attack” genannt. Das vereinfachte Protokoll: 2. B → A: RB (64 bit) 3. A → B: EncKAB,Auth(RB) (128 bit) dh ohne die Identitäten ID, kann angegriffen werden, indem der Angreifer O sofort die Zufallszahl RB reflektiert und an B zurücksendet. B beantwortet diese parallele zweite Session mit dem berechneten Wert EncKAB,Auth(RB), welchen O seinerseits als Antwort verwendet. 4 zeigt eine schematische Darstellung einer solchen Reflektionsattacke bei einfacher Authentifizierung.
  • Eine einfache Gegenmaßnahme, ohne zusätzliche implizite Annahme über das Verhalten von A und B, ist die Einbeziehung der Identität in den zu verschlüsselnden Text, dh EncKAB,Auth(RB||IDB).
    • (v) An Stelle der Verschlüsselungsfunktion Enc kann in dem Protokoll auch eine Keyed Hashfunktion HMAC, eine allgemeine Hashfunktion, wie SHA-256, oder ein Message Authentication Code (MAC), wie CBC-MAC, verwendet werden. Diese Realisierungsoptionen würden aber alle zu höherem Aufwand führen.
    • (vi) Auf die Authentifizierung der Challenge, dh B → A: RB,MAC(RB) wird in diesem Ausführungsbeispiel aus Aufwandsgründen und unter Beachtung der Bemerkungen in (iii) verzichtet.
    • (vii) Das hier beispielhaft vorgeschlagene Protokoll ist ein sogenanntes ”two-pass unilateral authentication protocol with nonces” (einseitiges Zwei-Pass-Authentifizierungsprotokoll mit nur einmal verwendeten Zahlen). In der Kryptographie sucht man immer nach einem Protokoll mit der geringsten Anzahl von Protokollpässen und trotzdem hohen Sicherheitseigenschaften. Allgemein kann gesagt werden, dass man meist mit einem Protokollpass weniger auskommt, wenn man statt der Nonces, Zufallszahlen, entweder einen Time Stamp (Zeitstempel) oder einen synchronen Counter, Sequence Number (Sequenzzähler/Sequenzzahl), verwendet. Der Zeitstempel oder der Zähler dürfen insbesondere nicht von A, dem Prover (Überprüfer), gesetzt bzw. zurückgesetzt werden dürfen. In diesem Fall kämen sämtliche Protokollaktionen von A und könnten somit aufgezeichnet sein.
  • Der entscheidende Punkt ist also: Falls nur eine unidirektionale Kommunikation von A nach B stattfinden kann und weder Zeitstempel noch Sequenzzähler, welche im System synchron und nicht manipulierbar vorhanden sein müssen, verwendet werden können, dann werden alle Protokollaktionen von A initiiert, B ist passiv, und der Prover/Claimant (Prüfer/Anforderer) A kann theoretisch alle Daten vorher aufzeichnen und einspielen. Es ist also prinzipiell nicht möglich, auf den Rückkanal zu verzichten und trotzdem die geforderte Sicherheit, beispielsweise durch implizite Authentifizierung, zu erreichen.
  • Hierzu wird verwiesen auf ”Walter Fumy and Hans-Peter Riess, Kryptographie, Entwurf; Einsatz und Analyse symmetrischer Kryptoverfahren, R. Oldenbourg Verlag, München, Wien, second edition, 1994”. Es wird dort gelehrt, dass der Einsatz von Zeitstempeln die Verfügbarkeit einer hinreichend exakten und zuverlässigen Systemzeit erfordert. Die verifizierende Instanz kann in diesem Fall die Gültigkeit einer Nachricht anhand des zugehörigen Zeitstempels überprüfen. Eine Nachricht wird akzeptiert, falls die Abweichung zwischen dem Zeitpunkt des Nachrichteneingangs und dem Zeitstempel einen Schwellwert nicht übersteigt. Soll ein Wiedereinspielen von Transaktionen auch innerhalb des tolerierten Zeitintervalls verhindert werden, so muss über die akzeptierten Nachrichten entsprechend lange Buch geführt werden. Dies ist allerdings im Sensorkontext unmöglich. Eine gewisse Schwierigkeit beim praktischen Einsatz von Zeitstempeln bildet die Synchronisation der Uhren bei den beteiligten Instanzen; problematisch kann aber auch deren häufig mangelhafte Manipulationssicherheit sein. Die Grundidee von Sequenznummern besteht darin, dass bei einem Authentifzzierungsmechanismus zu jeder Sequenznummer nur eine Nachricht oder eine Nachricht innerhalb eines bestimmten logischen Zeitraums akzeptiert wird. Die Verwendung von Sequenznummern erfordert einen gewissen Verwaltungsaufwand, der für jede entsprechende Kommunikationsbeziehung anfällt. Eine Mindestanforderung ist das Speichern der jeweils aktuellen Sequenznummer für jede Kommunikationsrichtung. Auch müssen beispielsweise für den Fall eines Systemausfalls, Synchronisationsmechanismen vorgesehen werden.
  • An Hand dieses Auszugs aus einem Kryptographielehrbuch sieht man, dass man auf irgendeine Form der bidirektionalen oder synchronen Kommunikation bei einer Authentifizierung nicht verzichten kann. Dies verneint für das Ausfürhungsbeispiel einer Sensor-Steuergerät-Kommunikation über einen PSI5-Bus eindeutig die Frage, ob man auf eine synchrone, bidirektionale PSI5-Kommunikation zwischen ECU und Sensor verzichten kann.
    • (viii) Der Vollständigkeit halber sei noch das entsprechende ”one-pass unilateral authentication protocol with time stamps/sequence counters” nach ISO/IEC 9798-2 angegeben. Siehe hierzu ”ISO/IEC 9798-2, Information technology – Security techniques – Entity Authentication – Part 2: Mechanisms using symmetric encipherment algorithms ISO/IEC, 1994”.
    A → B: EncKAB,Auth(TSA||IDB)||IDA mit TSA – Time Stamp, generiert von A. Die im Klartext übertragene IDA ist von keiner unmittelbaren kryptographischen Bedeutung, sie sind im ISO-Standard nicht vorhanden.
  • Im Folgenden wird auf Designprinzipien für kryptographische Protokolle eingegangen. Zum Design eines kryptographischen Protokolls gibt es einige Prinzipien, welche man beachten sollte. Es wird hierbei auf ”Colin Boyd and Anish Mathuria, Protocols for Authentication and Key Establishment, Springer, 2003, Seite 31” Bezug genommen.
  • Die in dieser Literatur angegebenen Protokolle können als Protokolle 3.4 und 3.5 dort gefunden werden, siehe Seiten 77 und 78, das Zeichen {}K steht für authenticated encryption mit Schlüssel K. A → B: {TA, B}KAB Protocol 3.4: ISO/IEC 9798-2 one-pass unilateral authentication protocol
    • 1. B → A: NB
    • 2. A → B: {NA, B}KAB
    Protocol 3.4: ISO/IEC 9798-2 two-pass unilateral authentication protocol
  • Der in der Literatur auf Seite 80 aufzufindenden Tabelle 3.2 kann man entnehmen, dass beide Protokolle 3.4 und 3.5 die gewünschten Eigenschaften Liveness, Freshness of key, und Entity Authentication von A erfüllen, und dass keine bekannten Angriffe existieren, obwohl kein formaler Sicherheitsbeweis existiert. Die Sicherheit beider Protokolle wurde in der Vergangenheit breit untersucht. Formale Sicherheitsbeweise von Protokollen sind erst in jüngster Zeit eine harte Anforderung an Standards. Die entstehenden Protokolle sind oft aus technischen Gründen etwas umfangreicher als die klassischen Authentifizierungsprotokolle. Das im Folgenden beispielhaft ausgewählte Protokoll, angelehnt an Protokoll 3.5, ist das günstigste aller dort dargestellten Protokolle, für welche bisher noch kein Angriff existiert.
  • Im Folgenden wird näher auf den Integitätsschutz der Sensordaten, den zweiten Schritt des Sicherheitsgesamtkonzeptes, eingegangen. Neben der Verhinderung des Austauschens von Sensoren kommt der Verhinderung bzw. genauer der Entdeckung und dem Nachweis von Modifikationen der Sensordaten eine sehr große Bedeutung zu. Kryptographische Techniken zum Schutz der Daten fokussieren auf den Ursprung der Daten, dh data origin authentication, integrity of sender, und auf die Integrität der Daten, integrity of data, dh den Fakt, dass die Daten nicht modifiziert wurden. Andere wichtige Aspekte sind die Timeliness, die Abfolge von Daten und ggf der beabsichtigte Empfänger. Diese Eigenschaften sind stark applikationsabhängig. Es stellt sich beispielsweise die Frage, ob der Replay von unmodifizierten Daten beispielsweise bei Paketverlusten ein kryptographischer Angriff ist. Daher werden in die kryptographischen Grundmechanismen selbst keine zeitlich abhängigen States (Zustände) eingebaut.
  • Im Folgenden werden die oben angegebenen Bezeichnungen verwendet. Seien also x = (x1, ..., xt) die t Message Text Blöcke der Blockbreite n, ggf nach dem durchgeführten Padding. Zur Erreichung des Ziels der Authentizität bzw. Integrität der Daten können im Wesentlichen drei kryptographische Zugänge unterscheiden werden: Authentifizierungscodes, digitale Signaturen und Message Authentication Codes.
  • Authentifizierungscodes sind kombinatorische Objekte, deren Erfolgswahrscheinlichkeit für einen Angriff explizit ausgerechnet werden kann und unabhängig von der Rechenleistung des Angreifers ist. Sie sind heutzutage relativ wenig verbreitet, oftmals wird für jede Transaktion ein neuer Schlüssel benötigt.
  • Digitale Signaturen sind asymmetrische Verfahren, welche um den Faktor 100 bis 1000 langsamer als symmetrische Verfahren sind. Im Fall asymmetrischer Verfahren verfügt jeder Sensor/Teilnehmer A über ein eigenes Schlüsselpaar pkA, skA (public key, secret/private key). Bei der Signatur hasht der Teilnehmer A die Nachricht x und wendet das Signaturgenerierungsverfahren GenSig mit seinem privaten Schlüssel skA an und sendet die resultierende Signatur s an B, dh A → B: x, s = GenSigskA(h(x)) B: gilt VerSigpkA(x', s)? Accept or Reject.B erhält die Nachricht x' und die Signatur s und überprüft mittels des Signaturverifikationsverfahrens VerSig unter Nutzung des authentischen public keys (öffentlichen Schlüssels) von A die Signatur. Heutzutage verwendet man z. B. im Automotive-Bereich meist RSA PKCS#1 v1.5 Signaturen:
    • 1. RSA 1024 bit: GenSig: 1024 bit1024bit, VerSig: 1024 bit16bit; Signatur, Modul, private Key je 128 byte, public Key ≈ 16 bit
    • 2. RSA 2048 bit: GenSig: 2048 bit2048bit, VerSig: 2048 bit16bit; Signatur, Modul, private Key je 256 byte, public Key ≈ 16 bit
  • Wesentlich bessere Eigenschaften haben ECC(Elliptic Curve Cryptography)-Signaturen.
    • 3. ECDSA 160 bit – Sicherheit vergleichbar mit RSA 1024 bit: GenSig: eine skalare Punktmultiplikation, VerSig: zwei skalare Punktmultiplikationen; Signatur 40 byte
    • 4. ECDSA 256 bit – Sicherheit vergleichbar mit RSA 2048 bit: GenSig: eine skalare Punktmultiplikation, VerSig: zwei skalare Punktmultiplikationen; Signatur 80 byte
  • Digitale Signaturen liefern zusätzlich zum Integritätsschutz die Eigenschaft der Nichtabstreitbarkeit, Non Repudiation Property, welche bei Disputen zwischen den Kommunikationspartnern rechtlich hilfreich sein kann. Da in dem beispielhaft beschriebenen Sensorkontext beide Kommunikationspartner innerhalb des Systems Auto arbeiten (Motor bzw. Steuergerät B sowie Sensor A) und das Steuergerät B selten eine vom Sensor A erhaltene Nachricht abstreiten wird, ist Nichtabstreitbarkeit in diesem konkreten Fall nicht notwendig.
  • Im Folgenden werden Message Authentication Codes erläutert. Wie im Obigen betrachtet, löst eine simple Verschlüsselung eines Tags, beispielsweise linearer Tag oder Hashdigest, das Problem der Authentizität von Nachrichten nicht. Ein Message Authentication Code besteht aus einem:
    • 1. Schlüsselgenerierungsalgorithmus: Output: symmetrischer Schlüssel K, Bitlänge k, beispielsweise k = 56 ... 256,
    • 2. MAC-Generierungsalgorithmus: Input: Text x, Schlüssel K, Output: MACK(x)-Bitstring der Länge m, beispielsweise m = 24 ... 128,
    • 3. MAC-Verifikationsalgorithmus: Input: Text x, MAC-Wert MACK(x), Schlüssel K, Output: Accept oder Reject.
  • Die Sicherheit eines MAC-Algorithmus kann informell wie folgt beschrieben werden – allgemein akzeptiertes Sicherheitsmodell: Es soll einem Angreifer praktisch unmöglich, computationally infeasible, sein, eine so genannte existential forgery, dh irgendeine zulässige Fälschung, zu generieren mittels einer so genannten adaptiven Chosen Text Attacke, dies umfasst insbesondere auch MAC-Verifikationsabfragen, siehe beispielsweise ”Jonathan Kahtz and Yehuda Lindell, Introduction to Modern Cryptography, CRC Publishing, 2007, Seite 16”. Wenn ein Message Authentication Code in diesem Sinne sicher ist, dann ist die Sicherheit insbesondere nicht abhängig von der speziellen Codierung der Daten.
  • Vier typische Attacken auf MAC-Algorithmen sind:
    • 1. Brute Force Schlüsselsuche → hinreichend großer Schlüsselraum, beispielsweise k ≥ 80 für medium term security
    • 2. Raten des MAC-Wertes → Erfolgswahrscheinlichkeit max(2–k, 2–m). Für die meisten Applikationen gilt k > m und m = 32 ... 64.
    • 3. Generische Fälschung basierend auf internen Kollisionen. Dies ist insbesondere bei den oben angegebenen, modifizierten vorgeschlagenen „Integritätsschutzverfahren” der Fall.
    • 4. Attacken basierend auf kryptoanalytischen Schwächen
  • Zur Erklärung der beiden letzten Angriffsszenarien wird zitiert aus ”Bart Preneel, MAC algorithms, In van Tilborg, siehe hierzu "Henk C. A. van Tilborg, editor, Encyclopedia of Cryptography and Security, Springer, 2005", Seite 365”.
  • Man unterscheidet zwischen MACs, welche auf Blockchiffren basieren, und MACs, welche auf dedizierten Hashfunktionen basieren. Vor einiger Zeit haben in den internationalen Gremien zusätzlich Arbeiten begonnen, um MACs mit so genannten universellen Hashfunktionen zu standardisieren, siehe ISO/IEC 9797-3. Diese sind allerdings noch nicht weit verbreitet.
  • Im Folgenden werden Keyed Hashfunctions – HMAC erläutert. Unter den Keyed Hashfunctions hat die HMAC-Konstruktion, siehe ”Mihir Bellare, Ran Canetti and Hugo Krawczyk, Keying hash functions for message authentication, In Neal Koblitz, editor, Proceedings of CRYPTO '96, volume 1109 of Lecture Notes in Computer Science, Seiten 1–15, Springer, 1996” am weitesten Verbreitung gefunden. Sie wird insbesondere im IETF-Umfeld, beispielsweise bei IPsec und http-digest, sehr oft eingesetzt. HMAC basiert auf dem zweimaligen, verschachtelten Hashen einer Nachricht x unter Verwendung eines geheimen Schlüssels K mit einer geeigneten Hashfunktion H. HMACK(x) := H(K ⊕ opad||H(K ⊕ ipad||x))
  • Die zwei Strings ipad, inner-padding, und opad, outer-padding, sind vorgegebene Stringkonstanten. Im Gegensatz zu MACs basierend auf Blockchiffren gibt es bei der HMAC-Konstruktion nicht eine Vielzahl von Padding-Methoden und optionalen Prozessen.
  • Weit verbreitet sind etwa HMAC-SHA-1, H = SHA-1, m = 96, dh nur 96 most significant bits der 160 bit Output, und HMAC-SHA-256, H = SHA-256, m = 96, dh nur 96 most significant bits der 256 bit Output, siehe etwa IPSec. HMAC wurde im Rahmen der Sensorabsicherung betrachtet, ist allerdings deutlich teurer als die letztendlich im konkreten Ausführungsbeispiel vorgeschlagene Lösung.
  • Im Folgenden werden MACs basierend auf Blockchiffren erläutert. Seien x1, x2, ... xt, die Blöcke von Message Texten, beispielsweise mit der Blocklänge n = 128 für den Algorithmus Enc = AES oder der Blocklänge n = 64 für die Algorithmen Enc = DES, Triple DES, IDEA oder PRESENT, dh: n = |x1| = ... = |xt'-1|
  • Mit t' sei die Anzahl der Blöcke vor dem so genannten Padding bezeichnet, dabei kann der letzte Block ggf weniger als n Bits umfassen, dh 0 < |xt'| ≤ n. Nach dem Padding erhält man t Message Text Blöcke x1, ..., xt, wobei je nach Paddingverfahren gilt:

    Padding Method 1: Der Plaintext wird mit keinem oder mehreren 0-Bits aufgefüllt bis ein Vielfaches der Blocklänge n erreicht ist, dh t = t'. Siehe hierzu ”A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996, Algorithm 9.29, Seite 334”.

    Padding Method 2: Dem Plaintext wird ein 1-Bit angehängt, danach wird mit 0-Bits aufgefüllt bis ein Vielfaches der Blocklänge n erreicht ist, dh t = t' oder t = t' + 1. Siehe hierzu ”A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996, Algorithm 9.30, Seiten 334–335”.

    Padding Method 3: Kodiere die Länge der ursprünglichen Nachricht in einem Längenblock L, meist 64 bit, ggf linksbündig mit 0-Bits auffüllen. Fülle die ursprüngliche Nachricht mit keinem oder mehreren 0-Bits auf bis ein Vielfaches der Blocklänge n erreicht ist, hänge den Längenblock L an, dh t = t' oder t = t' + 1.
  • Padding Method 3 wurde erst in der Version 1999, siehe ”ISO/IEC 9797-1, Information technology – Security techniques – Message Authentication Codes (MACS) Part 1: Mechanisms using a block cipher, ISO/IEC, 1999” des Standards für Message Authentication Codes ergänzt und war in vorherigen Versionen, siehe ”ISO/IPC 9797, Information technology – Security techniques – Data integrity mechanisms using a cryptographic check function employing block cipher algorithm, ISO/IEC, 1994” nicht enthalten. Dieses Paddingverfahren findet auch bei Hashfunktionen eine Anwendung.
  • Das erste Paddingverfahren hat schlechtere Sicherheitseigenschaften als die Methoden 2 und 3.
  • Der Einfachheit halber wird angenommen, dass in diesen message text Daten bereits zusätzliche Randomisierungsdaten, welche zur Abwehr so genannter Replay-Attacken benutzt werden, enthalten sind, mehr dazu wird im Folgenden angegeben.
  • Seien also x1, ..., xt die gepaddeten und ggf um Randomisierungsdaten ergänzten Druckwerte, message text. In dem konkreten Ausführungsbeispiel RDS-Sensorabsicherung etwa ist zur Zeit konkret geplant:
    • EncK
    – Verschlüsselungsalgorithmus AES mit Schlüssel K
    k
    – Länge des Schlüssels K in bit, hier k = 128
    n
    – Blockbreite des Verschlüsselungsalgorithmus, hier n = 128
    t
    – Anzahl der Blöcke, hier t = 16
  • Bei den Message Authentication Codes, welche auf Blockchiffren basieren, ist die CBC-MAC Konstruktion die meist verbreitete. Sei IV ein Initialization Vector der Länge n. Beim CBC-MAC kann im Gegensatz zu CBC-Encryption der Wert IV = 0n gewählt werden.
    H0 := IV = 0n Initialization
    Hi := EncK(Hi-1 ⊕ xi) i = 1, ..., t CBC mode
    MACK(x) := g(Ht) Output transformation
  • Im Folgenden gilt es zu bemerken:
    • (i) Im Anhang A des Standards ”ISO/IPC 9797, Information technology – Security techniques – Data integrity mechanisms using a cryptographic check function employing block cipher algorithm, ISO/IEC, 1994” werden außerdem zwei optionale Prozesse definiert: Optional process 1: Beim ersten optionalen Prozess wird mit einem zweiten unabhängigem Schlüssel K2 der letzte Block Ht noch einmal gesondert behandelt: der letzte Block Ht wird mit K2 entschlüsselt und mit K1 verschlüsselt. Dies entspricht g(Ht) := EncK1(DecK2(Ht)). Dieser Prozess nennt sich MAC-Strengthening und dient der Abwehr bestimmter chosen-text existential forgery Angriffe. Optional process 2: Der zweite optionale Prozess beinhaltet das nochmalige Verschlüsseln des letzten Blocks mittels eines zweiten Schlüssels K2, dh MAC := g(Ht) = EncK2(Ht).
    • (ii) Der neue Standard, siehe ”ISO/IEC 9797-1, Information technology – Security techniques – Message Authentication Codes (MACS) Part 1: Mechanisms using a block cipher, ISO/IEC, 1999” enthält keine optionalen Prozesse mehr, sondern spezifiziert stattdessen sechs unterschiedliche MAC-Algorithmen, welche jeweils mit den drei verschiedenen Padding-Methoden kombiniert werden können. Die MAC-Algorithmen 4 bis 5 sind neue Schemata. Zwei der dort vorgeschlagenen Verfahren sind auf Grund neuer kryptanalytischer Kenntnisse von 2003 nicht mehr als geeignet anzusehen. Die alten, bewährten Algorithmen sind:
    • 1. CBC-MAC ohne optionale Prozesse: gewöhnlicher CBC-MAC, dh g(Ht) = Ht. Bellare, Kilian und Rogaway, siehe ”M. Bellare, J. Kilian, and F.: 'Rogaway, The security of cipher block chaining, Journal of Computer and System Sciences, 3(61): 362–399, 2000”, konnten im Jahre 2000 zeigen, dass dieser CBC-MAC bei Nachrichten fester Länge sicher ist, wenn die zugrundeliegende Blockchiffre sicher ist, dh eine Pseudo Random Function ist. Man beachte, dass es sofort Angriffe gibt bei Nachrichten varaibler Länge, beispielsweise MACK(x||(x ⊕ MACK(x))) = MACK(x). Deshalb wird dieser einfache CBC-MAC in der Praxis nicht verwendet.
    • 2. CBC-MAC mit optionalem Prozess 1: Retail-MAC. Dieser MAC mit g(Ht) = msb63...32 EncK1(DecK2(Ht)) wurde erstmals für DES im Retail-Bankenbereich eingesetzt, daher der Name, dh m = n/2 = 32, n = 64, Eric – DES, k = 56 für K1 und K2. Die Modifikation des CBC-MAC derart, dass nicht der komplette letzte n-bit Block g(Ht) als MAC benutzt wird, sondern nur die m linksbündigen Bits davon, dient der Sicherheit gegen exhaustive key Attacken. In der Praxis ist oft m = n/2. Die Anwendung dieses CBC-MAC Verfahrens für die Integrität von Sensordaten wurde erstmals im RDS-Sensorworkshop am 29. Oktober 2008 vorgeschlagen. Wenn man DES als Verschlüsselungsalgorithmus einsetzt, so macht es keinen großen Unterschied im Implementierungsaufwand, sowohl in Software als auch in Hardware, ob man nur Verschlüsselung oder Ver- und Entschlüsselung benutzt. Beim AES ist aber der Overhead für eine Entschlüsselung gegenüber einer Verschlüsselung wesentlich größer. Daher wird in den darauffolgenden Sitzungen das nachfolgende Verfahren vorgeschlagen, welches nur mit Verschlüsselung auskommt.
    • 3. CBC-MAC mit optionalem Prozess 2: EMAC: Dieses Schema benutzt als Output-Transformation: g(Ht) = EncK2(Ht) = EncK2(EncK2(Ht-1 ⊕ xt)) mit einem zweiten Schlüssel K2. Die EMAC-Konstruktion wurde zuerst vom RIPE-Konsortium im Jahre 1995 vorgeschlagen. Petrank/Rackoff, siehe ”E. Petrank and C. Rackoff, CBC MAC for real-time data sources, Journal of Cryptology, 3(13): 315–338, 2000” gelang es mit diesem Schema erstmals, die Sicherheit von CBC-MACS bei Inputs variabler Länge zu beweisen. Dieses Schema wird als Realisierungsoption für die Sensorabsicherung vorgeschlagen, konkret Enc – AES, k = 128 für die Schlüssel K1 und K2, n = 128, m = m/2 = 54.
    • (iii) Eine weitere Optimierung von Black und Rogaway reduziert den Overhead durch das Padding. Der XCBC- oder Three-Key MAC, siehe ”J. Black and P. Rogawa, CBC MACs for arbitrary-length messages, In Mihir Bellare, editor, Advances in Cryptology – CRYPTO 2000, number 1880 in Lecture Notes in Computer Science, Seiten 197–215, Springer-Verlag, 2000” benutzt einen k bit Schlüssel K1 für die Blockchiffre und zwei n bit Schlüssel K2 und K3 für das so genannte Key Whitening, siehe ”T. Schütze, Algorithmen für eine Crypto-Library für Embedded Systems, Technical report, Robert Bosch GmbH, CR/AEA, August 2007, Internal document, Version 1.0, 2007-08-07, 46 pages” für die Grundidee des XOR-Encrypt-XOR Ansatzes. Der XCBC-MAC modifiziert die letzte Verschlüsselung und das Padding so, dass die Anzahl der Blöcke vor und nach Padding gleich ist, dh t = t': Falls |xt'| = n, dann xt = xt' ⊕ K2.Andernfalls hänge ein '1'-bit und j = n – |xt'| – 1 '0'-bits an und xt = (xt'||10j) ⊕ K3.
    • (iv) Natürlich ist noch ein weiterer Schlüssel K3 weniger vorteilhaft. Der OMAC-Algorithmus von Iwata und Kurosawa, siehe ”T. Iwata and K. Kurosawa. OMAC: One key CBC MAC, In T. Johannson, editor, Fast Software Encryption, number 2887 in Lecture Notes in Computer Science, Seiten 129–153, Springer-Verlag, 2003” reduziert den Aufwand auf einen Schlüssel, indem speziell K2 = '2' × EnCK1(0n) und K3 = '4' × EncK1(0n) gewählt wird.
  • Es ist zu erwähnen, dass '2' und '4' zwei Elemente im Galoisfeld GF(2n) sind, und dass × die Multiplikation in diesem Körper bezeichnet.
  • Es wird erwartet, dass NIST diesen Algorithmus unter dem Namen CMAC standardisieren wird. Siehe hierzu ”Morris Dworkin, Cipher Modes of Operation: The CMAC Mode for Authentication, NIST Special Publication 800-38b, National Institute of Standards and Technology NIST, May 2005, siehe http://csrc.nist.gov/publications/nistpubs/800-38b/sp800-38b.pdf, Seiten 2 und 3”.
  • Es wird für das Ausfürhungsbeispiel vorgeschlagen, diesen Algorithmus OMAC bzw. CMAC als Message Authentication Code für die Sensorabsicherung parallel zum EMAC zu untersuchen.
    • (v) Bei der CBC-Encryption werden selbstverständlich alle verschlüsselten Blöcke ausgegeben, beim CBC-MAC nur der letzte Block. Dies hat nicht nur technische Gründe. Ein CBC-MAC-Verfahren, welches alle Hi ausgibt, ist unsicher, siehe ”Jonathan Kahtz and Yehuda Lindell, Introduction to Modern Cryptography, CRC Publishing, 2007, Seite 126”.
  • Im Folgenden werden die vorgeschlagenen Integritätsschutzverfahren dargestellt und zusammengefasst. Wie bisher bezeichnen x = (x1, ..., xt') die Blöcke von Message Texten, Druckwerten, mit der Blocklänge n, Enc = {AES, PRESENT} die symmetrische Blockchiffre, dh k = 128 und n = 128 oder n = 64. Nach dem Padding, zur Auswahl stehen Padding Methode 1 oder 2, erhält man t Message Text Blöcke x = (x1, ..., xt). Um konkrete Zahlen präsentieren zu können, wird für die folgende Darstellung die zur Zeit geplante Realisierung beim RDS-Sensor ausgewählt:
    t = 16 Blöcke
    Enc AES, k = 128, n = 128
    Padding Methode 1
  • Im Folgenden wird das EMAC erläutert:
    H0 := IV = 0128 Initialization
    Hi := EncKAB,MAC1(Hi-1 ⊕ xi) i = 1, ..., t CBC mode
    MACK(x) := msb127...64[EncKAB,MAC2(Ht)] Output transformation
    mit den zwei 128 bit MAC-Schlüsseln KAB,MAC1 und KAB,MAC2, m = n/2 = 64, dh truncation of MAC Output, und der Output-Transformation EncKAB,MAC2(Ht).
  • Bei der zur Zeit betrachteten Variante ist die Anzahl der Bits 2048 durch die Blocklänge 128 teilbar, dh Padding-Methode 1 ist äquivalent zu keinem Padding. Für allgemeine Anwendungen dieses Sicherheitskonzeptes wird Padding-Methode 2 dringend empfohlen, ansonsten sollte das Verfahren wirklich nur für Input fester Länge verwendet werden. Der Sicherheitsbeweis für das Verfahren EMAC findet sich in ”E. Petrank and C. Rackoff, CBC MAC for real-time data sources, Journal of Cryptology, 3(13): 315–338, 2000”, dh existentially unforgeable under adaptive chosen-message attacks for variable input length. Das Verfahren ist in ”ISO/IEC 9797-2, Information technology – Security techniques – Message Authentication Codes MACs – Part 2: Mechanisms using a dedicated hash function, ISO/IEC; 2002” standardisiert. Der Aufwand besteht im Wesentlichen aus t + 1 Aufrufen der Blockchiffre.
  • Im Folgenden wird das CMAC/OMAC betrachtet. Seien K bzw. KAB,MAC1 der 128 bit MAC Schlüssel, K1, K2 bezeichnen zwei 128 bit abgeleitete Schlüssel. Seien weiterhin wie üblich x1, ..., xt-1, x't die Blöcke von Message Texten der Blocklänge n (n = 128 für AES). Für das CMAC-Verfahren gilt t' = t, dh die Anzahl der Blöcke vor und nach Nachbearbeitung („Padding”) des letzten Blockes ist gleich, es gilt sogar |xt| = |x't|, dh die Anzahl der Bits im letzten Block ist gleich, allerdings gilt nicht x't = xt. Der letzte Block wird vielmehr durch die XCBC-Konstruktion modifiziert.
  • Im Folgenden wird ein Algorithmus zur Subkey-Generierung beim CMAC erläutert.
    Input: Key K, Output: Sub Keys K1, K2
    S1: L := EncK(0128);
    S2: if(rnsb(L) = 0) then K1 := (L « 1) else K1 := (L « 1) ⊕ Rb;
    S3: if(msb(K1) = 0) then K2 := (K1 « 1) else K2 := (K1 « 1) ⊕ Rb;
  • Die Konstante Rb := 0 × 0 ... 087 für eine Blockchiffre der Blockbreite 128, dh beispielsweise AES, und RB := 0 × 0 ... 01B für eine 64 bit Blocklängenchiffre, beispielsweise Triple DES. Falls |x't| = n, dh der letzte Block x't ist komplett, dann setze xt := K1 ⊕ x't, sonst xt := K2 ⊕ (x't||10j)mit j = n – |x't| – 1. Mit diesen, nur im letzten Block gegenüber den Originaldaten veränderten, Message Blöcken x1, ..., xt wird nun der Standard-CBC-MAC-Algorithmus durchgeführt, bei Bedarf kann der Output bis auf 64 bit abgeschnitten werden:
    H0 := IV = 0128 Initialization
    Hi := EncKAB,MAC1(Hi-1 ⊕ xi) i = 1, ..., 1 CBC mode
    MACK(x) := msb127...64(Ht) Output transformation
  • Beim CMAC-Verfahren muss im Gegensatz zu EMAC selbst bei einer Anzahl der Bits, welche nicht durch die Blocklänge teilbar ist, kein Block zusätzlich angehängt werden. Man benötigt nur einen 128 bit MAC-Key KAB,MAC1. Zur Darstellung und Sicherheit des Verfahrens wird auf ”T. Iwata and K. Kurosawa, OMAC: One key CBC MAC, In T. Johannson, editor, Fast Software Encryption, number 2887 in Lecture Notes in Computer Science, Seiten 129–153, Springer-Verlag, 2003” und ”Morris Dworkin, Cipher Modes of Operation: The CMAC Mode for Authentication, NIST Special Publication 800–38b, National Institute of Standards and Technology (NIST), May 2005, siehe auch http://csrc.nist.gov/publications/nistpubs/800-38b/sp800-38b.pdf” verwiesen. Das Verfahren wird zur Zeit beim NIST standardisiert. Der Aufwand besteht in t Aufrufen der Blockchiffre, einer einmaligen Vorberechnung von EncK('0') sowie den GF(2128) bzw. Shift-Operationen.
  • Ob das Verfahren CMAC in der Praxis wirklich schneller und vor allem platz- bzw. speicherplatzsparender als EMAC realsiert werden kann, hängt ganz von der Implementierung der Blockchiffre und des kombinatorischen Overheads bei CMAC ab. Details können erst nach verschiedenen Implementierungstests mitgeteilt werden. Die MAC-Berechnung bzw. Verifikation findet auf Sensorseite (A) und Steuergeräteseite (B) im Wesentlichen gleich statt.
  • 5 zeigt eine schematische Darstellung zur Erläuterung eines Integritätsschutz der Sensordaten durch Message Authentication Codes EMAC oder CMAC:
    • A: Berechne 64 bit MAC-Wert mittels gemeinsamen Schlüssel K = KAB,MAC, entweder KAB,MAC = KAB,MAC1, KAB,MAC2 bei EMAC oder nur KAB,MAC = KAB,MAC1 bei CMAC aus den t Input Blöcken x = (x1, ..., xt) jeweils der Länge n:
      Figure 00270001
      Sende MAC-Wert zusammen mit den Message Texten x = (x1, ..., xt) an B A → B: x1, ..., xt, MACK(x) t × n bits, m bits = 2048 bits, 64 bits
    • B: erhält die Message Texte x1, ..., xt im Klartext, kann diese sofort zur Weiterverarbeitung ohne Latenzverzögerung weiterleiten und berechnet seinerseits MACK(x) und vergleicht abschließend mit dem übertragenen MAC-Wert von A. Im Fall der Nichtgleichheit wird ein Fehlersignal erzeugt, welches geeignet zu behandeln ist.
  • Im Folgenden wird als weiterer Teil des Sicherheitsgesamtkonzepts ein Verfahren zur Verhinderung von Replay-Attacken beschrieben. Da ein Message Authentication Code immer unabhängig von der Semantik der Daten sein sollte, wird wohlweislich in die Konstruktion von MACs kein zeitlich abhängiger State eingebaut. Wenn die Daten x = (x1, ..., xt) in obigem Protokoll also nur reine Druckdaten wären, so könnte ein Angreifer/Tuner für ihn interessante Motorsituationen bzw. Druckverläufe (Vollgas) aufzeichnen und später wieder einspielen (re-play). Um dieses Szenario zu verhindern, werden zusätzlich zu den Daten zufällige Elemente (Zufallszahlen, zeitvariante Parameter) in den Inhalt der Nachricht eingefügt, dh das Integritätsschutzverfahren, der MAC, selbst, bleibt unverändert. Auf Grund von Effizienzüberlegungen und Abschätzungen der Möglichkeiten für eine lokale Datenbank mit aufgezeichneten Druckdaten wird beispielsweise vorgeschlagen, mindestens r = 32 bit Zufallsdaten RA in jedem t × n = 16 × 128 = 2048 bit Block einzufügen. Aus kryptographischer Sicht wären ggf sogar r = 48 bit Zufallsdaten zu empfehlen. Da anzunehmen ist, dass die übertragenen eigentlichen Druckdaten auch noch eine gewisse Entropie besitzen, wird im Folgenden dieser Kompromis weiterverfolgt. Die eigentliche Aufteilung, dh an welcher Stelle kommen Druckdaten und wann kommen Zufallsbits, ist kryptographisch unbedeutsam. Der Vorschlag für das Ausführungsbeispiel RDS-Sensor ist wie folgt: 9 bit Druckdaten × 224 + r = 32 bit Zufallszahlen (RA) = 2048 = 128 × 16 = t × n. Damit werden Replay-Attacken beim Integritätsschutz wirksam verhindert. Ein Angreifer müsste mindestens 232+Entropie(x) Protokollläufe komplett aufzeichnen.
  • Im Folgenden wird demonstriert, wie man im entscheidenden vierten Schritt des erfindungsgemäßen Sicherheitskonzepts durch geschickte Verbindung beider Verfahren eine so genannte Transaktionsauthentifizierung erhält. Was zur Sensorabsicherung benötigt wird, ist mehr als eine reine Message authentication, nämlich auch die Uniqueness und Freshness. Es wird verwiesen auf ”A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996, Tabelle 9.10, Seite 362”. Die an dieser Literaturstelle angegebene Tabelle von Typen von Authentifizierung stellt sich wie folgt dar:
    Identification of source Data integrity Timeliness or unqiueness Defined in
    Message auth. Yes Yes - §9.6.1
    Transaction auth. Yes Yes Yes §9.6.1
    Entity auth. Yes - Yes $10.1.1
    Key auth. Yes Yes Desirable $12.2.1
  • Mit dem MAC zur Integritätssicherung (erste Zeile) wird keine Freshness erreicht. Dazu wird die Authentifizierung benutzt, hier vorletzte Zeile und Entity Authentication genannt. Man sieht hier, dass am besten eine Transaction Authentication wäre. Dies erfordert aber Message Authentication und entsprechend lange zeitvariante Parameter in jedem Paket. Also etwa ein MAC über die Druckdaten und einen ausreichend langen Zeitstempel oder einen (synchronisierten) Zähler. Da man auf dem Sensor standardmäßig weder eine Uhr noch einen synchronen Counter hat, wurde deshalb die Kombination aus Zeile 3 (entity authentication, Authentifizierung) und Zeile 1 (message authentication, Integritätsschutz) gewählt.
  • An dieser Stelle kommt die entscheidende Verbindung beider Protokolle. Bei der Authentifizierung schickt das Steuergerät B z. B. eine 64 bit Zufallszahl RB an den Sensor A. Beim Integritätsschutz sendet der Sensor z. B. eine 32 bit Zufallszahl RA an das Steuergerät.
  • Es wird nun beispielsweise für RA zu Beginn die 32 least significand bits von RB verwendet und in jedem Schritt, dh alle t × n = 2048 bit, der Wert von RA um Eins nach oben gezählt. Dadurch sind beide Protokolle kryptographisch sicher verbunden. Einem Angreifer nützt die Kenntnis des als Sequence Counter verwendeten lsb(RB) nichts, da dieser ja bei jeder Authentifizierung neu vom Steuergerät gewählt wird. Darüberhinaus entfällt auf Sensorseite A die Implementierung eines Zufallszahlengenerators, da alle Zufallszahlen vom Steuergerät B kommen. Auf Steuergeräten gibt es jedoch heute schon deterministische RNGs.
  • 6A und 6B zeigen eine schematische Darstellung zur Erläuterung eines Gesamtprotokolls einer Verbindung von Integritätsschutz und Authentifizierung zur Transaktionssicherheit der Sensordaten. Bei dem in der Figur angezeigten Gesamtprotokoll werden zur Verdeutlichung von der Abhängigkeit der eingefügten Zufallsbits die Druckdaten in der Form (x1, ..., xt|RA) geschrieben.
  • Eine wichtige Frage für die Implementierung ist nun, wie oft man den Integritätsschutz-Protokollschritt durchführen kann, ohne dass es zu einer Wiederholung des Sequence Counters RA kommt. Es wird angenommen, dass der 32 bit Counter einfach überläuft (unsigned int wrap), dh man kann 232 × (2048 – 32) bit von Druckdaten übertragen. Bei einer Datenübertragungsrate von 8000 × 9 bit pro Sekunde kommt es zu einer Wiederholung des Counters nach
    Figure 00300001
  • Nach dieser Zeit sollte spätestens eine Re-Authentifizierung erfolgen. Das Steuergerät B sendet ja selbst die Zufallszahl RB an den Sensor, damit kann es auch den Startwert für den Sequence Counter RA = lsb31...0(RB) berechnen. Mit jedem Datenpaket, dh alle t × n bit, erhält das Steuergerät einen neuen Wert R'A. Falls der übermittelte Wert R'A innerhalb eines gewissen Fensters von [RA, RA + ΔRA] ist, beispielsweise ΔRA := 3, dann akzeptiert das Steuergerät diesen Sequence Counter und setzt RA := R'A + 1. Wichtig ist, dass der Sensor von sich aus den Sequence Counter nicht resetten kann, vgl. schlechte Designlösung bei KeeLoq. Im Normalfall, dh ohne Paketverluste, sollte man mit ΔRA := 0 auskommen, dh RA wird mit jedem Paket nur um Eins inkrementiert.
  • An dieser Stelle wird ausdrücklich darauf hingeweisen werden, dass eine Transaktionsauthentifizierung, dh Integrität des Senders, Integrität der Daten sowie die Freshness, entweder mit einem bidirektionalen Kommunikationsprotokoll (Challenge-Response) oder mit einem globalen, unabhängigem Time Stamp oder Sequence Counter erreicht werden können. Der Claimant/Prover, in diesem Fall der Sensor, darf nicht in der Lage sein, den Counter oder die Uhr zu resetten. Dies kann wie im Fall von KeeLoq zu Denial of Service Attacken führen. Der Counter wird nur in einem bestimmten Gültigkeitswindow akzeptiert, der Angreifer manipuliert den Counter so, dass er immer ungültig ist. Daraus folgend wird der Sensor nicht akzeptiert oder muss neu angelernt werden. Bei Wegfahrsperren wird davon ausgegangen, dass der sich authentifizierende Fahrzeugschlüssel selbst tamper resistant ist, und auf diese Weise keine unnatürliche Counter erzeugt werden können. Sollte der interne Counter eines Fahrzeugschlüssels um mehrere 100000 vom letzten autorisierten Counter abweichen, so muss meist der Fahrzeugschlüssel neu angelernt werden.
  • Ein Vorteil der Erfindung ist, dass es die betrachteten Sicherheitsziele kryptographisch beweisbar sicher erreicht, im Gegensatz zu bisher vorgeschlagenen Verfahren. Somit wäre es das erste kryptographische Verfahren zur Sensorabsicherung im Automotive Bereich. Es zeichnet sich durch eine solide, theoretische Grundlage; eine sorgfältige Wahl der kryptographischen Mechanismen zur Umsetzung der Sicherheitsziele unter Berücksichtigung der besonderen Anforderungen im Embedded Systems Bereich sowie durch die Kopplung der Authentifizierung und des Integritätsschutzes aus. Durch diese besondere Form der kryptographischen Kopplung wird sogar auf Seite des Sensors die Notwendigkeit eines sicheren Zufallszahlengenerators hinfällig. Lediglich auf Seiten der ECU wird ein Zufallszahlengenerator benötigt. Die vorgeschlagene Realisierung verwendet den Basismechanismus symmetrische Blockverschlüsselung, realisiert durch AES oder ggf PRESENT, als grundlegendes Tool. Dadurch müssen nicht verschiedene Mechanismen implementiert werden und es kann ein wirkungsvoller Re-Use erfolgen, innerhalb dieser Anwendung sowie in anderen kryptographischen Aufgaben auf dem Steuergerät.
  • Verfahren aus dem Stand der Technik haben entweder ein deutlich niedrigeres Sicherheitsniveau (unsichere und/oder proprietäre Algorithmen) oder sind deutlich teurer als die vorgestellte Lösung.
  • Im Folgenden wird eine detaillierte Beschreibung des Verfahrens als eine Zusammenfassung des endgültigen Protokolls angegeben. Im Folgenden bezeichne A den RDS-Sensor und B das Automotive Steuergerät. Ferner seien IDA und IDB jeweils 32 bit lange Identitäten von A bzw. B, beispielsweise Seriennummern oder Typteilenummern. An dieser und den folgenden Stellen werden exemplarisch bestimmte Bitlängen genannt. Das Schema ist ansonsten frei parametrisierbar und auch nicht auf den RDS-Sensor beschränkt. Bei Überschreiten der Blocklänge, beispielsweise bei AES 128 bit, sind aber ggf einige Mechanismen leicht zu modifizieren, beispielsweise CBC-Encryption with Padding statt ECB-Mode für den Authentifizierungsschritt.
  • Beide Teilnehmer in dem System verfügen über vorher eingebrachte symmetrische Schlüssel: einen gemeinsamen 128 bit AES-Schlüssel KAB,Auth für die Authentifizierung sowie einen gemeinsamen 128 bit AES-Schlüssel KAB,MAC1 für den Message Authentication Code CMAC bzw. zwei gemeinsame 128 bit AES-Schlüssel KAB,MAC1, KAB,MAC2 für den Message Authentication Code EMAC.
  • Das Gesamtprotokoll ist außerdem in 6 gezeigt.
    • 1. B: In einem ersten Schritt erzeugt das Steuergerät B eine kryptographisch sichere 64 bit Zufallszahl RB. Dazu wird entweder ein deterministischer Zufallszahlengenerator (Pseudo-RNG) der Klasse K3 mittel bzw. hoch (oder besser K4 hoch) mit einem ausreichend guten Seed (Entropie 128 bit) benutzt oder alternativ ein physikalischer Zufallszahlengenerator der Klasse P1 mittel bzw. hoch (besser P2 hoch). B → A: RB||IDB Die Zufallszahl RB wird konkateniert mit der Identität IDB über den bidirektionalen PSI5-Kanal an den RDS-Sensor A geschickt.
    • 2. A: Der RDS-Sensor A verschlüsselt mit einem symmetrischen AES-Schlüssel KAB,Auth der Länge 128 bit das empfangene Datenpaket (RB||IDB) der Länge 96 bit. Dabei wird (RB||IDB) mit '0'-Bits bis auf die Länge 128 bit gepaddet. Von dem entstehendem Ergebnis EncKAB,Auth(RB||IDB) der Länge 128 bit werden die 64 most significant bits genommen und zusammen mit der Identität IDA an das Steuergerät B zurückgesendet. A → B: msb127...64[EncKAB,Auth(RB||IDB)]||IDA
    • 3. B: Gleich nachdem in Schritt 1 die Daten RB||IDB an den Sensor geschickt wurden, kann das Steuergerät B seinerseits damit beginnen msb127...64 [EncKAB,Auth(RB||IDB)] zu berechnen. Es vergleicht die aus Schritt 2A empfangenen Daten, sowohl msb127...64[EncKAB,Auth(RB||IDB)] als auch IDA. Nur im Fall, das je beide Werte übereinstimmen, wird das Protokoll fortgesetzt, der Sensor ist gegenüber dem Steuergerät authentifiziert. Im Fall, das nur ein Wert abweicht, wird eine Fehlermeldung Authentication of sensor failed generiert.
    • 4. A: Der Sensor speichert die 32 least significant bits der 64 bit Zufallszahl RB als 32 bit Sequence Counter RA ab. Seien x = (x1, ..., x't|RA) die um die Zufallszahl RA angereicherten Druckdaten, unterteilt beispielsweise in t = 16 Blöcke der Länge n = 128. Beim RDS-Sensor ist eine mögliche Aufteilung 9 bit × 224 Druckdaten + 32 bit Zufallszahl RA = 2048 bit = t × n. Es sind auch andere Aufteilungen denkbar, wichtig sind die 32 bit Zufallszahl RA. Wir unterscheiden im Folgenden zwischen zwei Möglichkeiten zur Berechnung eines Message Authentication Codes, EMAC bzw. CMAC. Falls die Datenlänge nicht durch 128 teilbar ist, dh |x| ≠ 0 mod 128 bzw. |x't| < n, dh der letzte Block ist nicht voll gefüllt, dann wird beim EMAC der letzte Block mit '0'-Bits aufgefüllt, Padding Method 1, x1 = x't||0 ... 0 → x = (x1, ..., xt|RA). Man beachte, dass der EMAC mit diesem Paddingverfahren, dh faktisch kein Padding, nur bei Blöcken fester Länge angewendet werden sollte, im Beispiel nur für 2048 bit. Beim CMAC-Verfahren werden aus dem Schlüssel K = KAB,MAC1 mittels des Algorithmus zur Subkey-Generierung beim CMAC die beiden Subschlüssel K1 bzw. K2 berechnet. S0: Rb := 0 × 0 ... 087; S1: L := EncK(0128); {einmalige Vorberechnung} S2: if(msb(L) = 0) then K1 := (L « 1) else K1 := (L « 1) ⊕ Rb; S3: if(msb(Ki) = 0) then K2 := (K1 « 1) else K2 := (K1 « 1) ⊕ Rb;
  • Falls gilt: |x't| = n, dh der letzte Block ist komplett gefüllt, dann setze xt := K1 ⊕ x't, sonst xt := K2 ⊕ (x't||10j)

    mit j = n – |x't| – 1. Da die Datenlänge und damit |x't| in dieser Anwendung vorher feststehen, wird also neben dem im NVM gespeicherten Schlüssel KAB,MAC1 nur ein weiterer volatiler Schlüssel K1 oder K2 benötigt. Dieser Schlüssel kann beim Startup on the fly berechnet werden.
  • In beiden Fällen, EMAC und CMAC, hat man nun t = 16 Blöcke der Länge n = 128, dh x = (x1, ..., xt|Ra). Der Sensor A kann für diese Daten den CBC-Prozess anstoßen, dh es gilt:
    H0 := IV = 0128 Initialization
    Hi := EncKAB,MAC1(Hi-1 ⊕ xi) i = 1, ..., t CBC mode
  • Im Fall des EMAC wird der letzte Block Ht nochmals mit einem weiteren Schlüssel KAB,MAC2 verschlüsselt: EMAC'K(x) := EncKAB,MAC2(Ht)
  • In beiden Fällen werden vom letzten Ergebnis nur die 64 most significant bits als MAC-Wert verwendet: EMACK(x) := msb127...64EMAC'K(x) = msb127...64[EncKAB,MAC2 (H1)] bzw. CMACK(x) := msb127...64(Ht)
  • Der m = 64 bit MAC-Wert MACK() wird zusammen mit den Originaldaten x = (x1, ..., x't|RA) über den PSI5-Kanal an das Steuergerät gesendet. Die Zwischenwerte H1, ..., Ht dürfen nicht veröffentlicht werden. Abschließend wird der Sequence Counter RA um Eins erhöht.
    • 5. B: Das Steuergerät B erhält die Originaldruckdaten x1, ..., x't und gibt diese unverändert unmittelbar an die Motorsteuerung weiter. Mit den empfangenen Daten x = (x1, ..., x't|RA) wird nun auf Seite des Steuergerätes seinerseits der MAC-Wert berechnet und mit dem empfangenen MAC-Wert verglichen. Im Fall, dass die Werte unterschiedlich sind, wird ein Fehlerzähler CIntegrityerror inkrementiert. Falls dieser Zähler über einer gewisse Schranke CIntegrityerror ist, so wird eine Fehlermeldung Message Authentication of sensor data failed repeatedly generiert. Falls beide MAC-Werte übereinstimmen, so wird CIntegrityerror zurückgesetzt. Da das Steuergerät den Ausgangswert für RA selbst gesendet hat, kann es überprüfen, ob der gesendete Sequence Counter R'A innerhalb des Intervalles [RA, RA + ΔRA] mit beispielsweise ΔRA := 3 liegt. Falls ja, akzeptiert es den Counter RA := R'A und führt obige Berechnungen durch. Falls RA
      Figure 00340001
      [RA, RA + ΔRA], dann haben Sensor A und Steuergerät B offensichtlich zu viele Pakete verloren bzw. die Synchronität ging verloren. Dann sollte eine Re-Authentifizierung erfolgen, u. a. zur Neuaushandlung von RA. Nach der MAC-Berechnung und Vergleich wird RA um Eins inkrementiert. Es wird in Schritt 4A mit dem weiteren Message Authentication Code zur Intergitätssicherung fortgefahren.
  • Zu dem vorgestellten Ausführungsbeispiel des erfindungsgemäßen Sicherheitsgesamtkonzepts gibt es Alternativen. Z. B. können die zeitvarianten Parameter RA neben Zufallszahlen auch durch Zeitstempel oder Sequenzähler realisiert werden. Weiterhin werden für RA im Beispiel die least significant bits (die am wenigsten signifikanten Bits) von RB herangezogen. Aber auch andere Möglichkeiten der Verknüpfung von RA und RB bieten sich an: Z. B. ein anderer Teil von RB oder mehrere Teile von RB oder – bei gleicher Länge – auch RA = RB. Auch möglich ist es, eine Funktion von RB für RA heranzuziehen, z. B. RB mehrfach oder Teile von RB mehrfach heranzuziehen oder nach einer Formel RA aus RB zu bestimmen.
  • In jedem Schritt der Transaktionsauthentifizierung wird RA um 1 inkrementiert im oben vorgestellten Ausführungsbeispiel. Auch andere Inkrementierungen oder auch andere Veränderungen nach festgelegten Regeln sind hierfür denkbar und können vorteilhaft sein. Auch die hier präferierten (kryptografischen) Methoden zur Authentifizierung und zum Integritätsschutz, bzw. zur Transaktionsauthentifizierung, sind lediglich beispielhaft und lassen sich auch durch andere in der Beschreibung genannte Alternativ-Verfahren oder auch nicht genannte, vergleichbare Methoden ersetzen.
  • Da der RDS-Sensor und das Steuergerät über den öffentlichen PSI5-Kanal kommunizieren, lassen sich die einzelnen Nachrichten des Protokolls gut nachverfolgen. Es kann also davon ausgegangen werden, dass man das gesamte Protokoll sehr gut nachweisen kann. Der Inhalt des MAC-Wertes dagegen sieht für einen unbeteiligten Beobachter wie Zufall aus, dies ist auch der Sinn des Message Authentication Codes. Die Benutzung der verwendeten kryptographischen Verfahren lässt sich durch Analyse der Blocklängen, der Länge des MACs sowie durch Seitenkanalanalysen relativ sicher nachweisen.
  • Gerade auch im Automobilbereich ist ein Einsatz eines manipulationssicheren RDS-Sensors sehr vorteilhaft. Dort wird häufig explizit eine 100%ige Erkennung von Manipulationen angefordert. Eine einfache Verschlüsselung der Daten ist oft nicht ausreichend. Das vorgestellte Konzept ist dabei allgemein einsetzbar, es ist nicht auf den Fall RDS-Sensor mit PSI5-Schnittstelle beschränkt.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • - „ISO/IEC 9798-2, Information technology-Security Techniques-Entity Authentication – Part 2 Mechanisms using symmetric encipherment algorithms”. ISO/IEC, 1999 [0003]
    • - ISO/IEC 9797-1. Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher. ISO/IEC, 1999 [0003]
    • - ISO/IEC 9797-2. Information technology – Security techniques – Message Authentication Codes (MACs) – Part 2: Mechanisms using a dedicated hash-function. ISO/IEC, 2002 [0003]
    • - FIPS 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, November 2001, http://csrc.nist.gov/ [0022]
    • - A. Bogdanov, L. R. Knudsen, G. Leander, C. Paar, A. Poschmann, M. J. B. Robshaw, Y. Seurin, and C. Vikkelsoe, PRESENT: An ultra-lightweight block cipher, in P. Pallier and I. Verbauwhede, editors, Proceedings of CHES 2007, volume 4727 of Lecture Notes in Computer Science, Seiten 450–467, Springer-Verlag, 2007 [0022]
    • - ISO/IEC 9798-2 [0039]
    • - ISO/IEC 9798-2, Information technology – Security techniques – Entity Authentication – Part 2: Mechanisms using symmetric encipherment. algorithms ISO/IEC, 1994 [0039]
    • - http://www.bsi.bund.de/zertifiz/zert/interpr/ais20.pdf [0039]
    • - http://www.bsi.bund.de/zertifiz/zert/interpr/ais3i.pdf [0040]
    • - http://www.bsi.bund.de/zertifiz/zert/interpr/trngkr31.pdf [0040]
    • - Walter Fumy and Hans-Peter Riess, Kryptographie, Entwurf; Einsatz und Analyse symmetrischer Kryptoverfahren, R. Oldenbourg Verlag, München, Wien, second edition, 1994 [0044]
    • - ISO/IEC 9798-2 [0045]
    • - ISO/IEC 9798-2, Information technology – Security techniques – Entity Authentication – Part 2: Mechanisms using symmetric encipherment algorithms ISO/IEC, 1994 [0045]
    • - ISO/IEC 9798-2 [0047]
    • - ISO/IEC 9798-2 [0047]
    • - Jonathan Kahtz and Yehuda Lindell, Introduction to Modern Cryptography, CRC Publishing, 2007, Seite 16 [0056]
    • - Bart Preneel, MAC algorithms, In van Tilborg, siehe hierzu ”Henk C. A. van Tilborg, editor, Encyclopedia of Cryptography and Security, Springer, 2005”, Seite 365 [0058]
    • - ISO/IEC 9797-3 [0059]
    • - A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996, Algorithm 9.29, Seite 334 [0064]
    • - A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996, Algorithm 9.30, Seiten 334–335 [0064]
    • - ISO/IEC 9797-1, Information technology – Security techniques – Message Authentication Codes (MACS) Part 1: Mechanisms using a block cipher, ISO/IEC, 1999 [0065]
    • - ISO/IPC 9797, Information technology – Security techniques – Data integrity mechanisms using a cryptographic check function employing block cipher algorithm, ISO/IEC, 1994 [0065]
    • - ISO/IPC 9797, Information technology – Security techniques – Data integrity mechanisms using a cryptographic check function employing block cipher algorithm, ISO/IEC, 1994 [0070]
    • - ISO/IEC 9797-1, Information technology – Security techniques – Message Authentication Codes (MACS) Part 1: Mechanisms using a block cipher, ISO/IEC, 1999 [0070]
    • - M. Bellare, J. Kilian, and F.: 'Rogaway, The security of cipher block chaining, Journal of Computer and System Sciences, 3(61): 362–399, 2000 [0070]
    • - E. Petrank and C. Rackoff, CBC MAC for real-time data sources, Journal of Cryptology, 3(13): 315–338, 2000 [0070]
    • - J. Black and P. Rogawa, CBC MACs for arbitrary-length messages, In Mihir Bellare, editor, Advances in Cryptology – CRYPTO 2000, number 1880 in Lecture Notes in Computer Science, Seiten 197–215, Springer-Verlag, 2000 [0070]
    • - T. Schütze, Algorithmen für eine Crypto-Library für Embedded Systems, Technical report, Robert Bosch GmbH, CR/AEA, August 2007, Internal document, Version 1.0, 2007-08-07, 46 pages [0070]
    • - T. Iwata and K. Kurosawa. OMAC: One key CBC MAC, In T. Johannson, editor, Fast Software Encryption, number 2887 in Lecture Notes in Computer Science, Seiten 129–153, Springer-Verlag, 2003 [0070]
    • - Morris Dworkin, Cipher Modes of Operation: The CMAC Mode for Authentication, NIST Special Publication 800-38b, National Institute of Standards and Technology NIST, May 2005, siehe http://csrc.nist.gov/publications/nistpubs/800-38b/sp800-38b.pdf, Seiten 2 und 3 [0072]
    • - Jonathan Kahtz and Yehuda Lindell, Introduction to Modern Cryptography, CRC Publishing, 2007, Seite 126 [0073]
    • - E. Petrank and C. Rackoff, CBC MAC for real-time data sources, Journal of Cryptology, 3(13): 315–338, 2000 [0076]
    • - ISO/IEC 9797-2, Information technology – Security techniques – Message Authentication Codes MACs – Part 2: Mechanisms using a dedicated hash function, ISO/IEC; 2002 [0076]
    • - T. Iwata and K. Kurosawa, OMAC: One key CBC MAC, In T. Johannson, editor, Fast Software Encryption, number 2887 in Lecture Notes in Computer Science, Seiten 129–153, Springer-Verlag, 2003 [0080]
    • - Morris Dworkin, Cipher Modes of Operation: The CMAC Mode for Authentication, NIST Special Publication 800–38b, National Institute of Standards and Technology (NIST), May 2005, siehe auch http://csrc.nist.gov/publications/nistpubs/800-38b/sp800-38b.pdf [0080]
    • - A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996, Tabelle 9.10, Seite 362 [0084]

Claims (10)

  1. Verfahren zu einem Manipulationsschutz eines Sensors und von Sensordaten des Sensors, wobei im Rahmen einer Authentifizierung des Sensors eine Zufallszahl (RB) von einem Steuergerät an den Sensor geschickt wird, wobei die Sensordaten mit einem kryptographischen Integritätsschutz versehen werden, wobei den Sensordaten zusätzliche zeitvariante Parameter (RA) hinzugefügt werden und wobei die Sensordaten mit dem Integritätsschutz und den hinzugefügten zeitvarianten Parametern (RA) von dem Sensor an das Steuergerät geschickt werden, gekennzeichnet dadurch, dass für die zeitvarianten Parameter (RA) bei der Authentifizierung des Sensors die Zufallszahl (RB) oder ein Teil der Zufallszahls (RB) oder eine durch eine Funktion aus der Zufallszahl (RB) gewonnene Zahl herangezogen wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die zeitvarianten Parameter (RA) in jedem Schritt einer Transaktionauthentifizierung verändert werden.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Veränderung der zeitvarianten Parameter (RA) einer schrittweisen Inkrementierung entspricht.
  4. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Authentifizierung des Sensors nach einem Challenge-Response-Verfahren durchgeführt wird.
  5. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Integritätsschutz der Sensordaten nach einem MAC-Verfahren durchgeführt wird.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass als das MAC-Verfahren ein OMAC- oder ein EMAC-Verfahren verwendet wird.
  7. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die zeitvarianten Parameter durch Zeitstempel oder Sequenzzähler oder Zufallszahlen realisiert werden.
  8. Sensor, welcher Mittel aufweist, im Rahmen einer Authentifizierung des Sensors eine Zufallszahl (RB) von einem Steuergerät zu empfangen, Mittel aufweist, Sensordaten des Sensors mit einem kryptographischen Integritätsschutz zu versehen, Mittel aufweist, den Sensordaten zusätzliche zeitvariante Parameter (RA) hinzuzufügen, und Mittel aufweist, die Sensordaten mit dem Integritätsschutz und den hinzugefügten zeitvarianten Parametern (RA) an das Steuergerät zu senden, dadurch gekennzeichnet, dass der Sensor Mittel aufweist, für die zeitvarianten Parameter (RA) bei der Authentifizierung des Sensors die Zufallszahl (RB) oder einen Teil der Zufallszahls (RB) oder eine durch eine Funktion aus der Zufallszahl (RB) gewonnene Zahl heranzuziehen.
  9. Sensor nach Anspruch 8, dadurch gekennzeichnet, dass der Sensor Mittel aufweist, die zeitvarianten Parameter (RA) in jedem Schritt einer Transaktionauthentifizierung zu verändern.
  10. Sensor nach Anspruch 9, dadurch gekennzeichnet, dass die Veränderung der zeitvarianten Parameter (RA) einer schrittweisen Inkrementierung entspricht.
DE102009002396A 2009-04-15 2009-04-15 Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu Withdrawn DE102009002396A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102009002396A DE102009002396A1 (de) 2009-04-15 2009-04-15 Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu
US12/760,718 US8639925B2 (en) 2009-04-15 2010-04-15 Method for protecting a sensor and data of the sensor from manipulation and a sensor to that end

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102009002396A DE102009002396A1 (de) 2009-04-15 2009-04-15 Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu

Publications (1)

Publication Number Publication Date
DE102009002396A1 true DE102009002396A1 (de) 2010-10-21

Family

ID=42750838

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102009002396A Withdrawn DE102009002396A1 (de) 2009-04-15 2009-04-15 Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu

Country Status (2)

Country Link
US (1) US8639925B2 (de)
DE (1) DE102009002396A1 (de)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009045133A1 (de) 2009-09-29 2011-03-31 Robert Bosch Gmbh Verfahren zum Manipulationsschutz von Sensordaten und Sensor hierzu
DE102013206185A1 (de) 2013-04-09 2014-10-09 Robert Bosch Gmbh Verfahren zur Erkennung einer Manipulation eines Sensors und/oder von Sensordaten des Sensors
DE102013208730A1 (de) 2013-05-13 2014-11-13 Robert Bosch Gmbh Gesicherte Übertragung einer Folge von zu übertragenden Daten
DE102013218212A1 (de) 2013-09-11 2015-03-12 Robert Bosch Gmbh Verfahren zum abgesicherten Übermitteln von Daten
DE102015207220A1 (de) 2014-04-28 2015-10-29 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
DE102014212219A1 (de) 2014-06-25 2015-12-31 Robert Bosch Gmbh Verfahren zur Authentifizierung und Anbindung eines Geräts an ein Netzwerk sowie hierzu eingerichteter Teilnehmer des Netzwerks
DE102015202935A1 (de) 2015-02-18 2016-08-18 Robert Bosch Gmbh Verfahren zum Manipulationsschutz
DE102015209496A1 (de) 2015-05-22 2016-11-24 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
DE102015220038A1 (de) 2015-05-22 2016-11-24 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
EP3110101A1 (de) 2015-06-22 2016-12-28 Volkswagen Aktiengesellschaft Verfahren zu einem manipulationsschutz von über ein bussystem zwischen systemkomponenten zu übertragenden nutzdatenpaketen
WO2017064027A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102015220081A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Schlüssels in einer Schaltungsanordnung
WO2017064125A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102015220045A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
WO2017064075A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Schaltungsanordnung zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
WO2017064067A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur generierung eines schlüssels in einem netzwerk und zur aktivierung einer absicherung einer kommunikation in dem netzwerk auf basis des schlüssels
DE102015220083A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Schaltungsanordnung zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
WO2017064025A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
WO2017064129A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses für eine einmalverschlüsselung in einem netzwerk
DE102015221239A1 (de) 2015-10-30 2017-05-04 Robert Bosch Gmbh Verfahren und Vorrichtung zum Schützen von Datenintegrität durch ein eingebettetes System mit einem Hauptprozessorkern und einem Sicherheitshardwarebaustein
CN107306185A (zh) * 2016-04-20 2017-10-31 罗伯特·博世有限公司 用于避免对数据传输的操纵的方法和装置
EP3941018A1 (de) 2020-07-15 2022-01-19 Robert Bosch GmbH Verfahren und vorrichtungen zum bereitstellen und zum empfangen von messdaten und verfahren und vorrichtung zur kommunikation zwischen einem fahrzeugsensor eines fahrzeugs und einem steuergerät des fahrzeugs

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010011022A1 (de) * 2010-03-11 2012-02-16 Siemens Aktiengesellschaft Verfahren zur sicheren unidirektionalen Übertragung von Signalen
CN103141055A (zh) * 2011-01-25 2013-06-05 三洋电机株式会社 通信装置
EP2506174B1 (de) * 2011-03-30 2019-01-09 Irdeto B.V. Aktivierung einer softwareanwendung, die auf einer hardwarevorrichtung ausgeführt werden soll
US10019564B2 (en) 2014-03-28 2018-07-10 Cryptography Research, Inc. Authentication of a device
US9792440B1 (en) * 2014-04-17 2017-10-17 Symantec Corporation Secure boot for vehicular systems
US9955333B2 (en) 2014-08-20 2018-04-24 Qualcomm, Incorporated Secure wireless wake-up companion
US9609512B2 (en) * 2014-10-09 2017-03-28 Userstar Information System Co., Ltd. Wireless authentication system and wireless authentication method
EP3056706A1 (de) 2015-02-16 2016-08-17 Honeywell International Inc. Ansatz zur nachbehandlungssystemmodellierung und modellidentifizierung
EP3125052B1 (de) 2015-07-31 2020-09-02 Garrett Transportation I Inc. Quadratischer programmlöser für mpc mit variabler anordnung
US10272779B2 (en) 2015-08-05 2019-04-30 Garrett Transportation I Inc. System and approach for dynamic vehicle speed optimization
US9729318B2 (en) * 2015-10-05 2017-08-08 International Business Machines Corporation Using everyday objects as cryptographic keys
US10044696B2 (en) 2015-12-22 2018-08-07 Mcafee, Llc Simplified sensor integrity
WO2017147207A1 (en) * 2016-02-22 2017-08-31 Continental Automotive Systems, Inc. Method to establish and update keys for secure in-vehicle network communication
US10601859B2 (en) 2016-02-25 2020-03-24 Trusona, Inc. Anti-replay systems and methods
US10124750B2 (en) 2016-04-26 2018-11-13 Honeywell International Inc. Vehicle security module system
US10036338B2 (en) 2016-04-26 2018-07-31 Honeywell International Inc. Condition-based powertrain control system
US10728249B2 (en) 2016-04-26 2020-07-28 Garrett Transporation I Inc. Approach for securing a vehicle access port
US10104055B2 (en) * 2016-05-27 2018-10-16 David Joseph Ponder System and process of protecting client side information in electronic transactions
GB2551137B (en) * 2016-06-06 2019-10-30 Delphi Tech Ip Ltd Method to control unauthorised hacking of fuel injector operation control
JP6986548B2 (ja) * 2016-07-29 2021-12-22 トゥルソナ，インコーポレイテッド アンチリプレイ認証のシステムおよび方法
WO2018049234A1 (en) 2016-09-09 2018-03-15 Trusona, Inc. Systems and methods for distribution of selected authentication information for a network of devices
US10630481B2 (en) * 2016-11-07 2020-04-21 Ford Global Technologies, Llc Controller area network message authentication
WO2018101918A1 (en) 2016-11-29 2018-06-07 Honeywell International Inc. An inferential flow sensor
JP7051859B2 (ja) 2016-12-12 2022-04-11 トゥルソナ，インコーポレイテッド 光検出を用いたネットワーク対応アカウント作成のための方法及びシステム
US20180359090A1 (en) * 2017-06-08 2018-12-13 Qualcomm Incorporated Avoiding link integrity failures on displayport during hcdp 2.2 by using sink side optimizations
US11057213B2 (en) 2017-10-13 2021-07-06 Garrett Transportation I, Inc. Authentication system for electronic control unit on a bus
EP3841508A4 (de) * 2018-08-24 2022-04-20 Trusona, Inc. Authentifizierungssysteme und -verfahren mit wiedergabeschutz
EP3742663B1 (de) * 2019-05-20 2024-02-07 Nokia Technologies Oy Gemeinsame geheimnisgenerierung
US20240007296A1 (en) * 2020-12-01 2024-01-04 Continental Automotive Technologies GmbH Method for secure real-time message transmission between a transmitter and a receiver which are on board a motor vehicle

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6507907B1 (en) * 1999-02-26 2003-01-14 Intel Corporation Protecting information in a system
US6973187B2 (en) * 2000-01-31 2005-12-06 Vdg, Inc. Block encryption method and schemes for data confidentiality and integrity protection
FI20002453A (fi) * 2000-11-08 2002-05-09 Nokia Corp Adaptiivinen sanoman autentikointikoodi
US20030156715A1 (en) * 2001-06-12 2003-08-21 Reeds James Alexander Apparatus, system and method for validating integrity of transmitted data
AU2003244310A1 (en) * 2002-06-19 2004-03-11 Advanced Computer Systems, Inc. Inter-authentication method and device
JP4617763B2 (ja) * 2003-09-03 2011-01-26 ソニー株式会社 機器認証システム、機器認証サーバ、端末機器、機器認証方法、および機器認証プログラム
US7607012B2 (en) * 2003-10-01 2009-10-20 Nokia Corporation Method for securing a communication
JP4810289B2 (ja) * 2006-04-17 2011-11-09 ルネサスエレクトロニクス株式会社 メッセージ認証子生成装置、メッセージ認証子検証装置、及びメッセージ認証システム
US20080046731A1 (en) * 2006-08-11 2008-02-21 Chung-Ping Wu Content protection system
US8102999B2 (en) * 2006-08-18 2012-01-24 Medtronic, Inc. Secure telemetric link
KR101042839B1 (ko) * 2007-04-16 2011-06-20 재단법인서울대학교산학협력재단 무선 이동 통신 시스템에서 인증 시스템 및 방법
US8010778B2 (en) * 2007-06-13 2011-08-30 Intel Corporation Apparatus and methods for negotiating a capability in establishing a peer-to-peer communication link
KR100901697B1 (ko) * 2007-07-09 2009-06-08 한국전자통신연구원 저전력 ｓｈａ-1 해쉬 연산 장치 및 이를 이용한 저전력ｈｍａｃ 암호 장치
US7957533B2 (en) * 2007-10-02 2011-06-07 Alcatel-Lucent Usa Inc. Method of establishing authentication keys and secure wireless communication
US8347094B2 (en) * 2008-04-25 2013-01-01 International Business Machines Corporation Securing wireless body sensor networks using physiological data
US8230219B2 (en) * 2008-08-12 2012-07-24 Texas Instruments Incorporated Reduced computation for bit-by-bit password verification in mutual authentication
DE102009045133A1 (de) * 2009-09-29 2011-03-31 Robert Bosch Gmbh Verfahren zum Manipulationsschutz von Sensordaten und Sensor hierzu

Non-Patent Citations (21)

* Cited by examiner, † Cited by third party
Title
"ISO/IEC 9798-2, Information technology-Security Techniques-Entity Authentication - Part 2 Mechanisms using symmetric encipherment algorithms". ISO/IEC, 1999
A. Bogdanov, L. R. Knudsen, G. Leander, C. Paar, A. Poschmann, M. J. B. Robshaw, Y. Seurin, and C. Vikkelsoe, PRESENT: An ultra-lightweight block cipher, in P. Pallier and I. Verbauwhede, editors, Proceedings of CHES 2007, volume 4727 of Lecture Notes in Computer Science, Seiten 450-467, Springer-Verlag, 2007
A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996, Algorithm 9.29, Seite 334
Bart Preneel, MAC algorithms, In van Tilborg, siehe hierzu "Henk C. A. van Tilborg, editor, Encyclopedia of Cryptography and Security, Springer, 2005", Seite 365
E. Petrank and C. Rackoff, CBC MAC for real-time data sources, Journal of Cryptology, 3(13): 315-338, 2000
FIPS 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, November 2001, http://csrc.nist.gov/
http://www.bsi.bund.de/zertifiz/zert/interpr/ais20.pdf
http://www.bsi.bund.de/zertifiz/zert/interpr/ais3i.pdf
http://www.bsi.bund.de/zertifiz/zert/interpr/trngkr31.pdf
ISO/IEC 9797-1. Information technology - Security techniques - Message Authentication Codes (MACs) - Part 1: Mechanisms using a block cipher. ISO/IEC, 1999
ISO/IEC 9797-2. Information technology - Security techniques - Message Authentication Codes (MACs) - Part 2: Mechanisms using a dedicated hash-function. ISO/IEC, 2002
ISO/IEC 9797-3
ISO/IPC 9797, Information technology - Security techniques - Data integrity mechanisms using a cryptographic check function employing block cipher algorithm, ISO/IEC, 1994
J. Black and P. Rogawa, CBC MACs for arbitrary-length messages, In Mihir Bellare, editor, Advances in Cryptology - CRYPTO 2000, number 1880 in Lecture Notes in Computer Science, Seiten 197-215, Springer-Verlag, 2000
Jonathan Kahtz and Yehuda Lindell, Introduction to Modern Cryptography, CRC Publishing, 2007, Seite 126
Jonathan Kahtz and Yehuda Lindell, Introduction to Modern Cryptography, CRC Publishing, 2007, Seite 16
M. Bellare, J. Kilian, and F.: 'Rogaway, The security of cipher block chaining, Journal of Computer and System Sciences, 3(61): 362-399, 2000
Morris Dworkin, Cipher Modes of Operation: The CMAC Mode for Authentication, NIST Special Publication 800-38b, National Institute of Standards and Technology NIST, May 2005, siehe http://csrc.nist.gov/publications/nistpubs/800-38b/sp800-38b.pdf, Seiten 2 und 3
T. Iwata and K. Kurosawa. OMAC: One key CBC MAC, In T. Johannson, editor, Fast Software Encryption, number 2887 in Lecture Notes in Computer Science, Seiten 129-153, Springer-Verlag, 2003
T. Schütze, Algorithmen für eine Crypto-Library für Embedded Systems, Technical report, Robert Bosch GmbH, CR/AEA, August 2007, Internal document, Version 1.0, 2007-08-07, 46 pages
Walter Fumy and Hans-Peter Riess, Kryptographie, Entwurf; Einsatz und Analyse symmetrischer Kryptoverfahren, R. Oldenbourg Verlag, München, Wien, second edition, 1994

Cited By (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9100193B2 (en) 2009-09-29 2015-08-04 Robert Bosch Gmbh Method for protecting sensor data from manipulation and sensor to that end
WO2011039037A1 (de) 2009-09-29 2011-04-07 Robert Bosch Gmbh Verfahren zum manipulationsschutz von sensordaten und sensor hierzu
DE102009045133A1 (de) 2009-09-29 2011-03-31 Robert Bosch Gmbh Verfahren zum Manipulationsschutz von Sensordaten und Sensor hierzu
DE102013206185A1 (de) 2013-04-09 2014-10-09 Robert Bosch Gmbh Verfahren zur Erkennung einer Manipulation eines Sensors und/oder von Sensordaten des Sensors
US9252945B2 (en) 2013-04-09 2016-02-02 Robert Bosch Gmbh Method for recognizing a manipulation of a sensor and/or sensor data of the sensor
DE102013208730A1 (de) 2013-05-13 2014-11-13 Robert Bosch Gmbh Gesicherte Übertragung einer Folge von zu übertragenden Daten
US9432370B2 (en) 2013-05-13 2016-08-30 Robert Bosch Gmbh Secured transmission of a sequence of data to be transmitted
DE102013218212A1 (de) 2013-09-11 2015-03-12 Robert Bosch Gmbh Verfahren zum abgesicherten Übermitteln von Daten
US9602487B2 (en) 2013-09-11 2017-03-21 Robert Bosch Gmbh Method for the protected transmission of data
DE102015207220A1 (de) 2014-04-28 2015-10-29 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
WO2015165775A1 (de) 2014-04-28 2015-11-05 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder eines schlüssels in einem netzwerk
US10027476B2 (en) 2014-04-28 2018-07-17 Robert Bosch Gmbh Method for generating a secret or a key in a network
DE102014212219A1 (de) 2014-06-25 2015-12-31 Robert Bosch Gmbh Verfahren zur Authentifizierung und Anbindung eines Geräts an ein Netzwerk sowie hierzu eingerichteter Teilnehmer des Netzwerks
DE102015202935A1 (de) 2015-02-18 2016-08-18 Robert Bosch Gmbh Verfahren zum Manipulationsschutz
US10461938B2 (en) 2015-02-18 2019-10-29 Robert Bosch Gmbh Method for manipulation protection
WO2016188707A1 (de) 2015-05-22 2016-12-01 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
WO2016188667A1 (de) 2015-05-22 2016-12-01 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102015220038A1 (de) 2015-05-22 2016-11-24 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
US10841085B2 (en) 2015-05-22 2020-11-17 Robert Bosch Gmbh Method for generating a secret or a key in a network
DE102015209496A1 (de) 2015-05-22 2016-11-24 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
EP3110101A1 (de) 2015-06-22 2016-12-28 Volkswagen Aktiengesellschaft Verfahren zu einem manipulationsschutz von über ein bussystem zwischen systemkomponenten zu übertragenden nutzdatenpaketen
DE102015211451A1 (de) 2015-06-22 2017-01-05 Volkswagen Aktiengesellschaft Verfahren zu einem Manipulationsschutz von über ein Bussystem zwischen Systemkomponenten zu übertragenden Nutzdatenpaketen
US10079685B2 (en) 2015-06-22 2018-09-18 Volkswagen Ag Method for manipulation protection of a bus system between at least two system components
WO2017064067A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur generierung eines schlüssels in einem netzwerk und zur aktivierung einer absicherung einer kommunikation in dem netzwerk auf basis des schlüssels
DE102015220048A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
WO2017064131A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102015220024A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
DE102015220057A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Schaltungsanordnung zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
DE102015220083A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Schaltungsanordnung zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
DE102015220053A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Generierung eines Schlüssels in einem Netzwerk und zu Aktivierung einer Absicherung einer Kommunikation in dem Netzwerk auf Basis des Schlüssels
WO2017064025A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
WO2017064124A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Schaltungsanordnung zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102015220055A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
WO2017064129A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses für eine einmalverschlüsselung in einem netzwerk
WO2017064120A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines schlüssels in einer schaltungsanordnung
DE102015220026A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses für eine Einmalverschlüsselung in einem Netzwerk
WO2017064075A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Schaltungsanordnung zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
WO2017064027A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102015220081A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Schlüssels in einer Schaltungsanordnung
WO2017064125A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102015220045A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
US10404717B2 (en) 2015-10-30 2019-09-03 Robert Bosch Gmbh Method and device for the protection of data integrity through an embedded system having a main processor core and a security hardware module
DE102015221239A1 (de) 2015-10-30 2017-05-04 Robert Bosch Gmbh Verfahren und Vorrichtung zum Schützen von Datenintegrität durch ein eingebettetes System mit einem Hauptprozessorkern und einem Sicherheitshardwarebaustein
US9894081B2 (en) 2016-04-20 2018-02-13 Robert Bosch Gmbh Method and device for avoiding manipulation of a data transmission
DE102016206630A1 (de) 2016-04-20 2017-11-09 Robert Bosch Gmbh Verfahren und Vorrichtung zur Vermeidung von Manipulation einer Datenübertragung
CN107306185A (zh) * 2016-04-20 2017-10-31 罗伯特·博世有限公司 用于避免对数据传输的操纵的方法和装置
CN107306185B (zh) * 2016-04-20 2022-01-18 罗伯特·博世有限公司 用于避免对数据传输的操纵的方法和装置
EP3941018A1 (de) 2020-07-15 2022-01-19 Robert Bosch GmbH Verfahren und vorrichtungen zum bereitstellen und zum empfangen von messdaten und verfahren und vorrichtung zur kommunikation zwischen einem fahrzeugsensor eines fahrzeugs und einem steuergerät des fahrzeugs
DE102020208806A1 (de) 2020-07-15 2022-01-20 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtungen zum Bereitstellen und zum Empfangen von Messdaten und Verfahren und Vorrichtung zur Kommunikation zwischen einem Fahrzeugsensor eines Fahrzeugs und einem Steuergerät des Fahrzeugs

Also Published As

Publication number Publication date
US20100268949A1 (en) 2010-10-21
US8639925B2 (en) 2014-01-28

Similar Documents

Publication Publication Date Title
EP2484047B1 (de) Verfahren zum manipulationsschutz von sensordaten und sensor hierzu
DE102009002396A1 (de) Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu
DE102011120968B4 (de) Erzeugen von sicheren Schlüsseln auf Anforderung
DE102013206185A1 (de) Verfahren zur Erkennung einer Manipulation eines Sensors und/oder von Sensordaten des Sensors
US7715553B2 (en) Encrypting a plaintext message with authentication
DE102010042539B4 (de) Datensender mit einer sicheren, aber effizienten Signatur
DE102009061045B4 (de) Erzeugung eines Session-Schlüssels zur Authentisierung und sicheren Datenübertragung
DE102010002241B4 (de) Vorrichtung und Verfahren zur effizienten einseitigen Authentifizierung
DE102018216915A1 (de) System und Verfahren für sichere Kommunikationen zwischen Steuereinrichtungen in einem Fahrzeugnetzwerk
DE102016210786A1 (de) Komponente zur Anbindung an einen Datenbus und Verfahren zur Umsetzung einer kryptografischen Funktionalität in einer solchen Komponente
DE102019113026A1 (de) Automobile nonce-missbrauchs-widerstandsfähige authentifizierte verschlüsselung
DE102013206202A1 (de) Sensormodul und Verfahren zum Betreiben eines Sensorsmoduls
EP1278332B1 (de) Verfahren und System zur Echtzeitaufzeichnung mit Sicherheitsmodul
EP3304802B1 (de) Verfahren zur sicherstellung der informationssicherheit von über einen datenbus übertragenen daten sowie datenbussystem
DE112012000971B4 (de) Datenverschlüsselung
DE102020121533A1 (de) Vertrauenswürdige authentifizierung von automotiven mikrocon-trollern
EP3506144A1 (de) Verfahren und system zum überprüfen einer integrität einer kommunikation
DE102019204608B3 (de) Vorrichtungen und Verfahren zum Erzeugen und zur Authentisierungsprüfung mindestens eines in einem Bus-System (BU) eines Kraftfahrzeugs zu übertragenden Datenpakets
EP3206154B1 (de) Verfahren und vorrichtungen zum sicheren übermitteln von nutzdaten
DE102021001095A1 (de) Zählerbasiertes Verfahren zum Erkennen verlorengegangener und wiedereingespielter Nachrichten
DE102019216203A1 (de) Auf Blockverschlüsselung basierender Proof-of-Work
WO2023066689A1 (de) Verfahren zur verschlüsselung eines klartextes
DE102023115999A1 (de) Verfahren, Vorrichtung, System und Computerprogrammprodukt zur PQ-sicheren Aktualisierung einer Datenverarbeitungseinheit
DE102008010787B4 (de) Verfahren zur Sicherung der Integrität von Daten
DE102022203725A1 (de) Verfahren zum Austausch kryptographischer Schlüssel zwischen Kommunikationsteilnehmern

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee