WO2011039037A1 - Verfahren zum manipulationsschutz von sensordaten und sensor hierzu - Google Patents

Verfahren zum manipulationsschutz von sensordaten und sensor hierzu Download PDF

Info

Publication number
WO2011039037A1
WO2011039037A1 PCT/EP2010/063168 EP2010063168W WO2011039037A1 WO 2011039037 A1 WO2011039037 A1 WO 2011039037A1 EP 2010063168 W EP2010063168 W EP 2010063168W WO 2011039037 A1 WO2011039037 A1 WO 2011039037A1
Authority
WO
WIPO (PCT)
Prior art keywords
sensor
cryptographic
authentication message
time
authentication
Prior art date
Application number
PCT/EP2010/063168
Other languages
English (en)
French (fr)
Inventor
James Newsome
Robert Szerwinski
Jan Hayek
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 CN201080043299.9A priority Critical patent/CN102577228B/zh
Priority to IN473DEN2012 priority patent/IN2012DN00473A/en
Priority to EP10754456.1A priority patent/EP2484047B1/de
Priority to US13/498,954 priority patent/US9100193B2/en
Priority to JP2012531314A priority patent/JP5584767B2/ja
Publication of WO2011039037A1 publication Critical patent/WO2011039037A1/de

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/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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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
    • 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/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • 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
    • 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/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
    • 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/08—Randomization, e.g. dummy operations or using noise
    • 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

Definitions

  • the present invention relates to a method for manipulation protection of sensor data and a sensor for this purpose.
  • the method according to the invention makes it possible to achieve transaction authentication of sensor data, in which case even if a key, e.g. By side channel attacks, the tamper protection is not compromised. This results in even more robust manipulation protection for sensor data with minimal additional effort.
  • the time-variant parameters are changed in each step of transaction authentication.
  • This process corresponds to one Sequence counter and allows a particularly close cryptographic coupling of the process parts authentication and transaction authentication, and thus a further security gain.
  • Particularly advantageous because it is particularly easy to implement, if the change of the time-variant parameters corresponds to a gradual incrementation.
  • a particular embodiment is based on the fact that a first part of the cryptographic authentication message, which is generated in the context of authentication method by truncation from the cryptographic authentication message and transmitted from the sensor to the controller, and the second part of the cryptographic authentication message, which is not used to calculate the time-variant parameters
  • time-variant parameters in each step of the transaction authentication are calculated from a difference between initial parameters obtained from the cryptographic authentication message and current parameters, wherein the current parameters emerge from the initial parameters by incremental incrementation.
  • a challenge-response method is used as the authentication method, which is characterized by particularly high security. Also advantageous is the use of MAC methods for protecting the integrity of the sensor data, which likewise satisfy high security standards, with the extremely secure methods EMAC and OMAC being particularly expedient.
  • time-variant parameters are designed either as timestamps, sequence counters or as random numbers.
  • Figure 1 is a schematic representation of a system for
  • Figure 2 is a schematic representation of a system for
  • Figure 3 is a schematic representation of a system for
  • Figure 4 is a schematic representation for explaining a
  • Figure 5 is a schematic representation for explaining a
  • Figures 6A, 6B is a schematic illustration of an exemplary
  • Integrity protection a close cryptographic coupling of both parts and at the same time saves the implementation of a random number generator on the sensor side. Moreover, with the method or sensor proposed here, it is achieved that even if one of the keys, e.g. by a side channel attack, the tamper protection is not broken.
  • FIG. 1 shows a schematic representation of a system for authenticating a sensor A in a control unit B by means of a challenge-response method.
  • the control unit B sends a request, "Challenge” to the sensor B, which responds to the authentication with a response "Response”.
  • a concrete method is schematically displayed, which is part of a comprehensive security concept, which high
  • this is a challenge-response method for authenticating the RDS sensor at the ECU.
  • Authentication is to determine whether, at the time of authentication, the RDS has a valid authentication feature, that is to say knowledge of a cryptographic key, and to bind this feature firmly to its identity, for example a serial number (keywords Freshness, Liveliness of Key).
  • Controller B transmitted data, where the "tag" represents the time-variant parameters.
  • These time-variant parameters are cryptographically checked after the processing of the print data and a manipulation of the RDS data is detected cryptographically secure, that is, there are no additional latencies in the real-time data processing by the
  • Integrity protection so-called Message Authentication Codes MAC are proposed.
  • CBC-MAC methods two more cryptographic keys are used, in another modified proposal, the so-called OMAC, one comes even with only one additional
  • Integrity key off As an implementation option for the RDS sensor with the digital PSI5 interface are proposed specifically: EMAC and CMAC, also known as OMAC. Both methods use a symmetric
  • random numbers are inserted into the data to be protected by integrity protection. These random numbers are transmitted in plain text to the ECU and verified by MAC.
  • the authentication should be done soon after a motor start, that is in the first few minutes. However, it is not necessary to put them right in the startup phase perform.
  • the integrity protection takes place only after the authentication, before this integrity protection cryptographically makes no sense. While the authentication takes place relatively infrequently, at least after each engine start and after loss of multiple packets or the synchronicity, the
  • Print data is continuously provided with an integrity tag, that is
  • integrity protection is used by default for each print package, either the MAC data should be ignored prior to authentication, which is inconvenient or used with the random numbers present on the RDS sensor. After successful authentication, the negotiated sequence counter is used.
  • Authentication by means of a challenge-response method (encryption of a challenge and identity); Integrity protection by means of message authentication codes based on the CBC mode together with appropriate padding and MAC strengthening, ie EMAC and CMAC; Prevention of replay attacks by adding random numbers and the pure user data; Secure cryptographic binding of both protocol parts by using part of the challenge as a sequence counter for integrity protection; For all
  • Mechanisms are only a single basic building block, a symmetric block cipher needed - as an implementation option concrete AES-128 or alternatively PRESENT proposed; Furthermore, due to the connection of the two protocol parts only a random number generator is needed on the control unit.
  • A be the RDS sensor and B be the ECU.
  • the goal is the
  • Authentication of A to B that is, A tells B that he has a shared secret, a cryptographic key, at the time of authentication. Both participants in the protocol have three shared keys: AB.Auth ⁇ shared authentication key
  • ID A and ID B are system-wide unique identities of the subscribers, such as 32-bit long serial numbers or
  • Type part numbers The length of the serial numbers is cryptographically not significant. It is important that all participants in the overall system, i. not just an engine / vehicle, can be clearly identified. This plays a key role in key management, as described later.
  • R A and R B are A and B, respectively
  • A encrypts the message R B
  • step 3 In order to save communication bandwidth, only the most significant 64 bits of the encryption are transmitted in step 3 and consequently also compared in 4. This is not synonymous with the application of a 64 bit block width encryption scheme.
  • A encrypts the message R B II ID B , that is, Enc K AB, Auth (RB II ID B ), and returns the 64 most significant bits along with ID A to B
  • a -> B msbi27 e 4 [Enc K AB.Auth (R B II ID B )] II ID A (64 bit
  • the security concept step proposed here is essentially the ISO / 1 EC 9798-2 two-pass unilateral authentication protocol. See "ISO / 1 EC 9798-2, Information technology - Security techniques - Entity Authentication - Part 2: Mechanisms using Symmetry eneipherment algorithms ISO / 1 EC, 1994". This applies except for the modification of the transmission of only the 64 most sigificant bits of Enc.
  • a -> B Enc KA B, Auth (RB) (128 bit) ie without the identities ID, can be attacked by the attacker O immediately reflecting the random number R B and sending it back to B.
  • B answers this parallel second session with the calculated value Enc K AB, Auth (RB), which O in turn uses as a response.
  • FIG. 4 shows a schematic representation of such a reflection attack with simple authentication.
  • Encrypting text that is Enc K AB, Auth (RB II ID B ).
  • a key hash function H MAC instead of the encryption function Enc, a key hash function H MAC, a general hash function, such as SHA-256, or a message authentication code (MAC), such as CBC-MAC, can also be used in the protocol.
  • MAC message authentication code
  • the protocol proposed here by way of example is a so-called "two-pass unilateral authentication protocol with nonces" (one-sided two-pass authentication protocol with only once used numbers).
  • Cryptography is always searched for a protocol with the least number of protocol passports and nevertheless high security properties. Generally it can be said that one usually gets by with a protocol pass less, if instead of the nonces, random numbers, either a time stamp (time stamp) or a synchronous counter, sequence number
  • sequence counter (Sequence counter / sequence number) used.
  • the time stamp or the counter must not be set by A, the Prover (Verifier).
  • time stamps requires the availability of a sufficiently accurate and reliable system time.
  • the verifying authority can check the validity of a message based on the corresponding time stamp.
  • a message is accepted if the difference between the time of the message input and the time stamp does not exceed a threshold. If a re-importing of transactions is to be prevented even within the tolerated time interval, a correspondingly long book must be maintained about the accepted messages. However, this is impossible in the sensor context. A certain difficulty in the practical use of
  • Timestamping forms the synchronization of the clocks among the participating instances; But problematic can also be their often poor security against manipulation.
  • sequence numbers are that at a
  • Sequence number for each communication direction is also, for example, in the event of a system failure, synchronization mechanisms must be provided.
  • a -> B ⁇ T A , B ⁇ K AB Protocol 3.4: ISO / 1 EC 9798-2 one-pass unilateral authentication protocol
  • Protocol 3.4 ISO / 1 EC 9798-2 two-pass unilateral authentication protocol
  • the following section deals in detail with the integrity protection of the sensor data, the second step of the overall safety concept.
  • the prevention or, more precisely, the detection and the detection of modifications of the sensor data is of very great importance.
  • Cryptographic techniques for data protection focus on the origin of data, that is, data origin authentication, integrity of sender, and integrity of data, that is, the fact that the data has not been modified.
  • Other important aspects are the timeliness, the sequence of data and, if necessary, the intended recipient.
  • Authentication codes are combinatorial objects whose
  • Probability of success for an attack can be explicitly calculated and is independent of the computing power of the attacker. They are relatively infrequent nowadays, often requiring a new key for each transaction.
  • Digital signatures are asymmetric methods that are slower than symmetric methods by a factor of 100 to 1000.
  • each sensor / subscriber A has its own key pair pk A , sk A (public key, secret / private key).
  • sk A public key, secret / private key
  • GenSig signature generation method
  • RSA 1024 bits GenSig: 1024 bit 1024 bit, VerSig: 1024 bit 16 bit; Signature, module, private key per 128 byte, public key »16 bit
  • RSA 2048 bit GenSig 2048 bit 2048 bit, VerSig 2048 bit 16bit; Signature, module, private key per 256 byte, public key »16 bit
  • ECC Elliptic Curve Cryptography
  • a message authentication code consists of a:
  • Rates of the MAC value -> success probability max (2 "k , 2 " m ). For most applications k> m and m 32 ... 64.
  • Hashfunctions - HMAC The following is an explanation of Keyed Hashfunctions - HMAC.
  • HMAC construction see "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, pp 1-15, Springer, 1996. "Widely used. It is very often used in the LETF environment, for example IPsec and http-digest.
  • HMAC is based on the twice, nested hash of a message x using a secret key K with a suitable hash function H.
  • H MACK (X): H (K ⁇ opad
  • the two strings ipad, inner-padding, and opad, outer-padding, are default string constants.
  • H MAC construction does not have a variety of padding methods and optional processes.
  • HMAC was considered as part of the sensor protection, but is significantly more expensive than the ultimate in the specific embodiment
  • Padding Method 3 was first published in 1999, see "ISO / I EC 9797-1, Information Technology - Security techniques - Message Authentication Codes (MAC S ) Part 1: Mechanisms using a block cipher, ISO / I EC, 1999" of the Standards for Message Authentication Codes was and was not included in previous versions, see “ISO / IPC 9797, Information technology - Security techniques - Data integrity mechanisms using a cryptographic check function employing block cipher algorithm, ISO / I EC, 1994". This padding method is also used for hash functions.
  • the first padding method has worse safety properties than methods 2 and 3.
  • this message text data already contains additional randomization data, which are used for repelling so-called replay attacks, more details are given below.
  • RDS sensor protection for example, is currently planned specifically:
  • n 128
  • the EMAC design was first proposed by the RIPE consortium in 1995. Petrank / Rackoff, see E. Petrank and C.
  • the number of bits 2048 is divisible by the block length 128, that is, padding method 1 is equivalent to no padding.
  • Padding Method 2 is strongly recommended, otherwise the procedure should really only be used for fixed length input.
  • Security evidence for the EMAC method can be found in "E. Petrank and C. Rackoff, CBC MAC for real-time data sources, Journal of Cryptology, 3 (13): 315-338, 2000", ie, existentially unforgeable under adaptive chosen -message attacks for variable input length.
  • the method is standardized in "ISO / 1 EC 9797-2, Information technology - Security techniques - Message Authentication Codes MACs - Part 2: Mechanisms using a dedicated hash function, ISO / 1 EC, 2002".
  • the effort essentially consists of t + 1 calls to the block cipher.
  • FIG. 5 shows a schematic representation for explaining one
  • Integrity protection of sensor data using EMA or CMAC message authentication codes :
  • the integrity assurance MAC (first line) does not achieve any freshness.
  • the authentication is used here, penultimate line and entity
  • Authentication is newly selected by the controller. Moreover, the implementation of a random number generator is omitted on sensor side A, since all random numbers come from the control unit B. On ECUs, however, there are already deterministic RNGs today.
  • a transaction authentication ie integrity of the sender, integrity of the Data as well as the freshness, either with a bidirectional communication protocol (challenge response) or with a global, independent time stamp or sequence counter can be achieved.
  • the claimant / prover in this case the sensor, must not be able to reset the counter or the clock. This can lead to denial of service attacks, as in the case of KeeLoq.
  • the counter is only in a specific
  • Validatewindow accepts the attacker manipulates the counter so that it is always invalid. As a result, the sensor is not accepted or must be newly trained. Immobilizers assume that the authenticating vehicle key itself is tamper resistant and thus can not generate unnatural counters. If the internal counter of a vehicle key deviates by several 100,000 from the last authorized counter, the vehicle key usually has to be newly taught.
  • the attacker can, for example, after breaking the integrity protection (known to Kmac), splits the transaction (ie the session): it computes the values for the integrity protection for data it has chosen (since Kmac is known) and uses the original source to successfully pass the challenge-response protocol complete.
  • Kmac integrity protection
  • the attacker can, for example, after breaking the integrity protection (known to Kmac), splits the transaction (ie the session): it computes the values for the integrity protection for data it has chosen (since Kmac is known) and uses the original source to successfully pass the challenge-response protocol complete.
  • SCAs could be made more difficult by increasing the minimum allowable time between two sub-protocol flows. This results in a reduction of the possible sample rate during the attack and thus increases the time wall for a successful attack. During an increase of this minimum period in the subprotocol integrity protection protocol narrow limits are set by the required data rate, a much higher value can be used in the authentication.
  • the concept described below represents an effective and efficient measure against breaking the overall protocol in the event of successful session splitting attacks (eg S CA attacks) against a sub-protocol To connect both sub-protocols together so that z.
  • Kmac eg, by SCA, which can be more difficult to prevent here than in the other sub-protocol
  • the proposed change preserves the positive characteristics of the original protocol in terms of resources and security.
  • the basis of the proposed variant is the secure derivation of a secret value from the challenge and from Kauth. This value then serves as the initial value R a0 of the nonce (number only used once) R a , which enters into each MAC calculation.
  • this initial value is formed directly from the challenge, a value known to the attacker.
  • FIG. 6 and Figures 6a and 6b show a schematic representation for explaining an overall protocol of a combination of integrity protection and authentication for transaction security of the sensor data in the newly proposed variant.
  • the communication of the sensor A with the control unit B is shown.
  • the sensor data of the sensor A to the control unit B are designated by x.
  • the sensor A and the control unit B have a common key K A B, Auth, z.
  • K A B, Auth, z As a 128-bit AES key, for authentication and a common key K A B, MAC, ZB
  • FIG. 6a shows first steps of the overall security concept, more precisely the description of a challenge-response method.
  • the control unit B generates a cryptographically secure 64-bit random number R B and sends it concatenated with the identity ID B to the sensor A: B -> A: R B II ID B.
  • the sensor A encrypts with a symmetric AES key K A B, Auth the received data packet (R B IIID B ). From the resulting result
  • the control unit B can in turn begin to calculate msbi 2 7... 64 [Enc K AB, Auth (RB IIID B )]. It then compares the received data, both msbi 2 7 ... 6 4 [Enc K AB.Auth (RB II ID B )] and ID A. Only in the case that both values match, the protocol is continued, the sensor is authenticated to the controller. If only one value deviates, an "Authentication of sensor failed" error message will be generated.
  • R b is already encrypted with ID b in the sensor to calculate the authentication response.
  • MSB 64 Enc Kauth (Rb
  • the last 8 bytes are kept secret by truncation.
  • the initial R a (R a0) is now derived from Enc K AB, Auth (RB II ID B), for example as the LSB 64 (Enc K aut h (Rb II I Db), so it is z. B.
  • the sensor stores the 64 as shown in Figure 6b least significant bits (Isb) of Enc K AB, Auth (RB II ID B ) IIID A as R A , or as the initial value R a0 of the Nonce R A.
  • an already calculated part from the challenge-response method of the authentication for example the part which was not sent (response truncation / response truncation), is used as the initial value R a0 .
  • the sensor data are designated x as described. in the
  • a message authentication code eg EMAC or CMAC
  • the sensor data x, concatenated with time-variant parameters, are sent together to the msb 64 of the Message Authentication Code MAC K Mac to the controller, see Figure 6b.
  • the time-variant parameters or the current nonce are transmitted unencrypted. However, this is no longer possible in the modified protocol proposed here since this would weaken the authentication of the response (truncation) of the authentication.
  • a -> B x II Isb32 (c)
  • sequence counter R A is increased by one.
  • the control unit B receives the sensor data x and processes these and / or passes them on. With the received data, the MAC value is now calculated on the controller side in turn and compared with the received MAC value. Since the control unit knows the output value for c, or R A , it can check whether the transmitted sequence counter c lies within a predetermined interval. If so, accept it and do the above
  • the second and third parts LSB 64 correspond to Enc K AB, Auth (RB
  • the second and third parts do not have to be identical. It may be advantageous if the first part does not interfere with the second and the third part overlaps or is at least not identical with them.
  • the second and third parts may be identical, overlap, or represent separate parts of Enc K AB, Auth (RB
  • the current parameter R a is calculated at every sensor data transaction, the time-variant parameters c at each sensor data transaction correspond to the difference from the initial value R a0 , in the example LSB 64 Enc K AB, Auth (RB
  • R A is incremented by 1 in the embodiment presented above.
  • Other increments or other changes according to defined rules are conceivable and may be advantageous.
  • Also preferred are the (cryptographic) methods for authentication and integrity protection
  • Transactional authentication are merely exemplary and can also be replaced by other alternative methods mentioned in the description or also comparable methods not mentioned above.
  • the number R B was called random number in the presented concept. More generally, it can also be provided as a nonce (number only used once), eg in addition to a random number as a time stamp or sequence counter.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zu einem Manipulationsschutz von Sensordaten sowie einen Sensor hierzu. Dabei wird im Rahmen einer Authentifizierung des Sensors eine einmalig verwendete Zahl von einem Steuergerät an den Sensor geschickt, wobei der Sensor eine kryptographische Authentifizierungsnachricht unter Verwendung der einmalig verwendeten Zahl generiert und zumindest einen ersten Teil der kryptographischen Authentifizierungsnachricht an das Steuergerät sendet. Weiterhin werden die Sensordaten mit einem kryptographischen Integritätsschutz versehen, wobei den Sensordaten zeitvariante Parameter hinzugefügt werden und wobei die Sensordaten mit dem kryptographischen Integritätsschutz und den hinzugefügten zeitvarianten Parametern von dem Sensor an das Steuergerät geschickt werden. Dabei wird für die Berechnung initialer Parameter zumindest ein zweiter Teil der kryptographischen Authentifizierungsnachricht und für die Berechnung des kryptographischen Integritätsschutzes zumindest ein dritter Teil der kryptographischen Authentifizierungsnachricht herangezogen und die zeitvarianten Parameter werden unter Verwendung der initialen Parameter berechnet.

Description

Beschreibung Titel
Verfahren zum Manipulationsschutz von Sensordaten und Sensor hierzu Stand der Technik
Die vorliegende Erfindung betrifft ein Verfahren zu einem Manipulationsschutz von Sensordaten und einen Sensor hierzu.
In der nicht vorveröffentlichten Schrift DE-102009002396 der Anmelderin wird ein Verfahren zum Manipulationsschutz von Sensordaten beschrieben, welches sich dadurch auszeichnet, dass durch die Verknüpfung von Authentifizierung des
Sensors und Integritätsschutz der Sensordaten eine Transaktionsauthentifizie- rung erreicht wird und damit ein stark erhöhter Schutz gegen Manipulation der Sensordaten gewährleistet ist.
Offenbarung der Erfindung
Vorteile der Erfindung
Das erfindungsgemäße Verfahren, bzw. der erfindungsgemäße Sensor, ermöglichen es, eine Transaktionsauthentifizierung von Sensordaten zu erreichen, bei welcher auch bei Verlust eines Schlüssels, z.B. durch Seitenkanal-Attacken, der Manipulationsschutz nicht ausgehebelt ist. Damit ergibt sich mit minimalem zusätzlichen Aufwand ein noch robusterer Manipulationsschutz für Sensordaten.
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 Inkrementie- rung entspricht.
Eine besondere Ausführung geht davon basiert darauf, dass sich ein erster Teil der kryptographischen Authentifizierungsnachricht, welcher im Rahmen des Au- thentifizierungsverfahren durch Trunkierung aus der kryptographischen Authentifizierungsnachricht generiert und von dem Sensor an das Steuergerät übertragen wird, und der zweite Teil der kryptographischen Authentifizierungsnachricht, welcher zur Berechnung der zeitvarianten Parameter herangezogen wird, nicht
überschneiden.
Besonders vorteilhaft ist es, wenn die zeitvarianten Parameter in jedem Schritt der Transaktionsauthentifizierung aus einer Differenz zwischen aus der kryptographischen Authentifizierungsnachricht gewonnenen initialen Parameter und aktuellen Parametern berechnet werden, wobei die aktuellen Parameter durch schrittweise Inkrementierung aus den initialen Parametern hervorgehen. Dadurch wird zu den bisherigen Vorteilen auch eine mögliche Antwort-Trunkierung aus dem Authentifizierungsverfahren nicht geschwächt.
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.
Es zeigen:
Figur 1 eine schematische Darstellung eines Systems zur
Authentifizierung eines Sensors A bei einem Steuergerät B mittels eines Challenge-Response-Verfahrens,
Figur 2 eine schematische Darstellung eines Systems zum
Integritätsschutz der Sensordaten,
Figur 3 eine schematische Darstellung eines Systems zur
Authentifizierung eines Sensors A bei einem Steuergerät B,
Figur 4 eine schematische Darstellung zur Erläuterung einer
Reflektionsattacke bei einfacher Authentifizierung,
Figur 5 eine schematische Darstellung zur Erläuterung eines
Integritätsschutz der Sensordaten durch Message Authentication Codes EMAC oder CMAC, und
Figuren 6A, 6B eine schematische Darstellung eines beispielhaften
Gesamtprotokolls zur Erläuterung der erfindungsgemäßen
Verbindung von 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 Sicher- heitsgewährleistung der Kommunikation zwischen einem beliebigen Steuergerät und einem Sensor konzipiert ist.
Betrachtet man die Anforderungen an die Absicherung von Kommunikationskanälen, so sind hauptsächlich die folgenden zu betrachten:
(1) [Message authentication] Schutz der Integrität der Daten
(2) [Entity authentication] Sicherstellen der Authentizität der Quelle
(3) [Confidentiality] Schutz der Vertraulichkeit der Daten (optional)
Zusätzlich zu diesen Grundanforderungen werden weitere abgeleitet, die spezielle Angriffstypen erschweren oder verhindern, welche nicht explizit durch die Grundanforderungen abgedeckt sind, aber ihrem Wesen nach implizit angenommen werden. Hier wären u.A. zu nennen:
(a) [Replay protection] Schutz vor Wiedereinspielung von Daten, die zwar integer sind (1), aber bereits schon einmal gesendet wurden.
(b) [Liveliness] Sicherstellen, dass die Quelle zum Zeitpunkt der Übertragung "am Leben' war, d.h., keine zu einem früheren Zeitpunkt vorausberechneten (oder aufgezeichneten und nicht gesendeten) Daten verwendet wurden.
Im Folgenden wird davon ausgegangen, dass die Daten nicht vertraulich sind, also (3) nicht benötigt wird. Dies kann z.B. bei Sensoren im Fahrzeugbereich der Fall sein. Die DE-102009002396 der Anmelderin hatte Protokolle zur Erreichung von (1), (2) zusammen mit (a) und (b) unter Berücksichtigung der beschränkten Ressourcen (Rechenzeit, Kanalkapazität) zum Inhalt. Die Grundidee ist hierbei der Einsatz eines Message Authentication Codes (MAC) zur Integritätssicherung, der Einsatz eines auf symmetrischer Kryptographie beruhenden Challenge- Response- Protokolls zur Quellauthentisierung und der Kombination dieser beiden Teile, um Transaktionsschutz zu erreichen. Beide Einzelprotokolle verfügen über jeweils einen eigenen symmetrischen Schlüssel (Kmac bzw. Kauth).
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 weitgehend aus der DE-102009002396 bekannt sind, ergeben sich die bedeutenden Unterschiede im entscheidenden vierten Schritt des erfindungsgemäßen Sicherheitskonzepts, welcher u.a. anhand von Figur 6 erläutert wird und auf einer Verknüpfung von Verfahrensschritten basiert. Um eine feste Bindung der Authentifizierung und des Integritätsschutzes zu erhalten, wird dabei vorgeschlagen, die Zufallszahlen beider Schritte, bzw. wie unten erläutert die zeitvarianten Parameter und die Zufallszahlen, bzw. Nonces (einmalig verwendeten Zahlen) der beiden Schritte, zu verbinden. Man erreicht durch diese Verbindung der beiden Teilschritte Authentifizierung und
Integritätsschutz eine enge kryptographische Kopplung beider Teile und spart gleichzeitig noch die Implementierung eines Zufallszahlengenerators auf der Sensorseite ein. Darüber hinaus wird mit dem hier vorgeschlagenen Verfahren bzw. Sensor erreicht, dass auch bei Verlust einer der Schlüssel, z.B. durch eine Seitenkanal-Attacke, der Manipulationsschutz nicht gebrochen wird.
Figur 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, das heißt 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).
Figur 2 zeigt eine schematische Darstellung eines Systems zum Integritätsschutz der Sensordaten. In diesem zweiten Schritt des Sicherheitskonzepts werden dabei nach der Authentifizierung - das heißt 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 Figur 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, das heißt 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 sogenannte 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-lnterface 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, das heißt 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.
Die Authentifizierung sollte zeitnah nach einem Motorstart erfolgen, das heißt 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, das heißt
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) x (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.
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, das heißt 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, das heißt 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: AB.Auth ■ gemeinsamer Authentifizierungsschlüssel
AB.MACI ■ gemeinsamer Message Authentication Code Schlüssel 1
AB,MAC2 ■ gemeinsamer Message Authentication Code Schlüssel 2
Im Fall des CMAC-Algorithmus genügt ein gemeinsamer Message Authentication Code Schlüssel 1, KAB,MACI- 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 I DA und I DB 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 gemäß DE-102009002396. Die Schritte 1-3 sind dabei schematisch in Figur 3 dargestellt.
1. B generiert eine 64 bit Zufallszahl RB
2. B sendet diese Zufallszahl RB zusammen mit seiner Identität I DB an A: B -> A: RB II I DB (64 bit||32 bit)
3. A verschlüsselt die Nachricht RB || I DB, das heißt EncK AB,Auth (RB II I DB) und schickt dies zusammen mit I DA an B zurück:
EncK AB.Auth (Re il I DB)|| I DA (128 bit II 32 bit) 4. B kann sofort nach Abschluss des Protokollschrittes in 2. damit beginnen, seinerseits den Response y = EncK AB,Auth (P»B II IDB) zu berechnen. Nach Erhalt der Antwort y' in 3. vergleicht er y mit der übermittelten Antwort y': gilt: y = y' = EncK AB,Auth (Re il IDB)?
Er vergleicht weiterhin die Identität von A mit der gewünschten, dh gilt: I DA = I D'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: msbi27 64[EncK AB.Auth (RB || IDB)] II 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 II I DB (64 bit || 32 bit)
3. A verschlüsselt die Nachricht RB II IDB, das heißt EncK AB,Auth (RB II IDB) und schickt die 64 most significant bits (höchstwertige Bits) zusammen mit IDA an B zurück
A -> B: msbi27 e4[EncK AB.Auth (RB II IDB)] II IDA (64 bit || 32 bit) 4. B kann sofort nach Abschluss des Protokollschrittes in 2. damit beginnen, seinerseits den Response y = msbi27 64[EncK AB,Auth (P»B II I DB)] zu berechnen. Nach Erhalt der Antwort y' in 3. vergleicht er y mit der übermittelten Antwort y': gilt: y = y' = msb127 64[EncK AB,Auth (RB H I DB)]?
Er vergleicht weiterhin die Identität von A mit der gewünschten, dh gilt: I DA = I D'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/1 EC 9798-2 two-pass unilateral authentication protocol. Siehe hierzu "ISO/1 EC 9798-2, Information technology - Security techniques - Entity Authentication - Part 2: Mechanisms using Symmetrie eneipherment. algorithms ISO/1 EC, 1994". Dies gilt bis auf die Modifikation der Übertragung lediglich der 64 most sigificant bits von Enc.
(ii) Zur Verhinderung von Replay-Attacken, das heißt 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: Funkti- onalitä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/zer1/interpr/ais20.pdf".
Mindestens sollte er die Eigenschaft PI 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/zer1 interpr/ais3i.pdf". Siehe hierzu auch„W. Killmann and W. Schindler, Ein Vorschlag zu: Funktionalitätsklassen und
Evaluationsmethodologie für physikalische Zufallszahlengeneratoren,
Technisches Papier zu AIS 31, Version 3.1, 25.9.2001, BSI, 2001, nachzulesen unter http://www.bsi.bund.de/zertifiz/zer1 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 x 232 Paaren (RB II msbi27...o EncK (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 Authenti- cation Protocols, In Secure Component and System Identification, März 2007, Workshop Record of S ECSI, 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 msbi27...o EncK (RB) hat eine Angriffskomplexität von 264"1 = 263. Die Identitäten I DA, I Db 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 II I DB, etwa durch Wahl einer 80 bit ID, länger als 128 bit werden, so ist zu beachten, dass dann für EncK (RB II I DB) ein sicherer Mode of Operation (Ausführungs- Modus) verwendet wird, etwa CBC-Encryption with random IV and padding, nicht mehr der simple ECB-Mode, das heißt 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 I RB I = 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 I D 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: EncK AB,Auth (RB) (128 bit) dh ohne die Identitäten I D, 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 EncK AB,Auth (RB), welchen O seinerseits als Antwort verwendet. Figur 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, das heißt EncK AB,Auth (RB II I DB).
(v) An Stelle der Verschlüsselungsfunktion Enc kann in dem Protokoll auch eine Keyed Hashfunktion H MAC, 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, das heißt 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/1 EC 9798-2 angegeben. Siehe hierzu "ISO/1 EC 9798-2, Information technology - Se- curity techniques - Entity Authentication - Part 2: Mechanisms using Symmetrie eneipherment algorithms ISO/1 EC, 1994".
A -> B : EnC|< AB.Auth (TSA H I Db) I I 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}K AB Protocol 3.4: ISO/1 EC 9798-2 one-pass unilateral authentication protocol
Figure imgf000017_0001
Protocol 3.4: ISO/1 EC 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 Authentifizierungspro- tokolle. 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, das heißt data origin authentication, integrity of sender, und auf die Integrität der Daten, integrity of data, das heißt 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 = (xi, ... , x 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 vi.5 Signaturen:
1. RSA 1024 bit: GenSig: 1024 bit1024bit, VerSig: 1024 bit16 bit; 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, das heißt 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 Lindeil, 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. Brüte 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/1 EC 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 lETF-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.
H MACK(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 H MAC- Konstruktion nicht eine Vielzahl von Padding-Methoden und optionalen Prozessen.
Weit verbreitet sind etwa HMAC-SHA-1, H=SHA-1, m = 96, das heißt nur 96 most significant bits der 160 bit Output, und HMAC-SHA-256, H=SHA-256, m = 96, das heißt 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 Xi, x2, .... Xf 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:
Figure imgf000021_0001
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, das heißt 0 < lxf| < n. Nach dem Padding erhält man t Message Text Blöcke Χι,... , xt, wobei je nach Paddingverfahren gilt:
Padding Method 1: Der Plaintext wird mit keinem oder mehreren O-Bits aufgefüllt bis ein Vielfaches der Blocklänge n erreicht ist, das heißt t = f. 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, das heißt 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, das heißt t = t' oder t = t'+ 1.
Padding Method 3 wurde erst in der Version 1999, siehe "ISO/I EC 9797-1, Information technology - Security techniques - Message Authentication Codes (MACS) Part 1: Mechanisms using a block cipher, ISO/I EC, 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/I EC, 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 Xi,..,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(Hj.i Φ Xj) i = 1, ... , t CBC mode
MACK(X) := g(H,) 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/1 EC, 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 Htwird mit K2 entschlüsselt und mit Ki verschlüsselt. Dies entspricht g(Ht) := EncKi(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, das heißt MAC := g(H,) = EncK2(H,).
(ii) Der neue Standard, siehe "ISO/1 EC 9797-1, Information technology - Security techniques - Message Authentication Codes (MACS) Part 1: Mechanisms using a block cipher, ISO/1 EC, 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, das heißt 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, das heißt eine Pseudo Random Function ist. Man beachte, dass es sofort Angriffe gibt bei Nachrichten varaibler Länge, beispielsweise MACK(x II (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 EncKi (DecK2 (Ht)) wurde erstmals für DES im Retail- Bankenbereich eingesetzt, daher der Name, das heißt m = n/2 = 32, n = 64, Enc - DES, k = 56 für Ki 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(EncKi(Ht-i Θ x ) 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 Ki 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 Ki 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, das heißt t = t':
Falls |Xf I = n, dann xt = Xf Θ K2.
Andernfalls hänge ein -bit und j = n - |xt |- 1 Ό'-bits an und xt = (xf || 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" x EnCKi (0n) und K3 = X4X x EncKi(0n) gewählt wird.
Es ist zu erwähnen, dass "2" und "4" zwei Elemente im Galoisfeld G F(2n) sind, und dass x 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, N IST 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ührungsbeispiel 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 H, ausgibt, ist unsicher, siehe "Jonathan Kahtz and Yehuda Lindeil, Introduction to Modern Cryptography, CRC Publishing, 2007, Seite 126".
Im Folgenden werden die vorgeschlagenen Integritätsschutzverfahren dargestellt und zusammengefasst. Wie bisher bezeichnen x = (χι,... , xt die Blöcke von Message Texten, Druckwerten, mit der Blocklänge n, Enc = { AES, PRESENT } die symmetrische Blockchiffre, das heißt 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 = (xi, 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 := EnC|< AB.MACI (Hu Θ Xj) i = 1, ... , t CBC mode
MACK(X) := msbi27...64_EncK AB,MAC2 (Ht)] Output transformation mit den zwei 128 bit MAC-Schlüsseln KAB,MACI und KAB,MAC2, m =n/2 = 64, das heißt truncation of MAC output, und der Output-Transformation Enci< AB,MAC2 (Ht).
Bei der zur Zeit betrachteten Variante ist die Anzahl der Bits 2048 durch die Blocklänge 128 teilbar, das heißt 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", das heißt existentially unforgeable under adaptive chosen-message attacks for variable input length. Das Verfahren ist in "ISO/1 EC 9797-2, Information technology - Se- curity techniques - Message Authentication Codes MACs - Part 2: Mechanisms using a dedicated hash function, ISO/1 EC; 2002" standardisiert. Der Aufwand besteht im Wesentlichen aus t + 1 Aufrufen der Blockchiffre.
Im Folgenden wird das CMAC / OMAC betrachtet. Seien K bzw. KAB,MACI der 128 bit MAC Schlüssel, Ki, K2 bezeichnen zwei 128 bit abgeleitete Schlüssel. Seien weiterhin wie üblich Xi,...,xt-i, 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, das heißt die Anzahl der Blöcke vor und nach Nachbearbeitung („Padding") des letzten Blockes ist gleich, es gilt sogar |xt| = |x't|, das heißt 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 Ki, K2
Sl: L := EncK(0128);
S2: if (rnsb(L) = 0) then Ki := (L « 1) eise Kl := (L « 1) ® Rb;
S3: if (msb(K!) = 0) then K2 := (Kl « 1) eise K2 := (Ki « 1) Θ Rb;
Die Konstante Rb := 0x0 ... 087 für eine Blockchiffre der Blockbreite 128, das heißt beispielsweise AES, und RB := 0x0 ... 01B für eine 64 bit
Blocklängenchiffre, beispielsweise Triple D ES. Falls lx'tl = n, das heißt der letzte Block x't ist komplett, dann setze xt := Ki Θ x't, sonst xt := K2 Θ (x't II 10j) mit j = n - |x't| - 1. Mit diesen, nur im letzten Block gegenüber den Originaldaten veränderten, Message Blöcken Xi, ... , xt wird nun der Standard-CBC-MAC- Algorithmus durchgeführt, bei Bedarf kann der Output bis auf 64 bit
abgeschnitten werden:
Figure imgf000028_0001
Initialization
Hi := EncK AB,MAci (Hu Θ Xj) i = 1, t 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,MACI- 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 EncKC0x) sowie den G F(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.
Figur 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,MACI, KAB,MAC2 bei EMAC oder nur KAB.MAC = KAB.MACI bei CMAC aus den t Input Blöcken x = (xi,..., Xt) jeweils der Länge n: EMACK (x)
MACK (x) :=
CMACK (x)
Sende MAC-Wert zusammen mit den Message Texten x = (xi, x an B
A -> B: Xi,.., xt, MACK(X) bits, m bits = 2048 bits, 64 bits
B: erhält die Message Texte Xi,..., 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 = (xi,..., 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, das heißt 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 x n = 16 x 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, das heißt 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 x 224 + r = 32 bit Zufallszahlen (R 0 = 2048 = 128 x 16 = t x 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:
Figure imgf000030_0001
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 (Transaktionsauthentifizierung) wäre. Dies erfordert aber Message Authentication (Nachrichtenauthentifizierung) 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 Zufallszahl RB an den Sensor A. Beim Integritätsschutz sendet der Sensor eine Zufallszahl RA an das Steuergerät. In der DE-102009002396 werden nun für RA zu Beginn die 32 least significant bits von RB verwendet und in jedem Schritt, das heißt alle t x 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.
Eine wichtige Frage für eine solche 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), das heißt man kann 232 x (2048 - 32) bit von Druckdaten übertragen. Bei einer Datenübertragungsrate von 8000 x 9 bit pro Sekunde kommt es zu einer Wiederholung des Counters nach
232 x (210 - 25 >
^ -1 » 5,9 x 107 s » 6MTage
8000 x9s_1
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 = lsb3i...0 (RB) berechnen. Mit jedem Datenpaket, das heißt alle t x 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 + ARÄ] ist, beispielsweise ARA := 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, das heißt ohne Paketverluste, sollte man mit ARA := 0 auskommen, das heißt RA wird mit jedem Paket nur um Eins inkrementiert.
An dieser Stelle wird ausdrücklich darauf hingeweisen werden, dass eine Transaktionsauthentifizierung, das heißt 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.
Während die Verknüpfung von Authentifizierung des Sensors und Integritätsschutz der Sensordaten gemäß DE-102009002396 also eine erhöhte Sicherheit des Gesamtskonzepts bewirkt, ist eine weitere Problematik noch ungelöst. Ein Verlust eines geheimen Schlüssels durch Seitenkanalattacken (side Channel at- tacks, SCA), wie z.B. Differentieller Leistungs-Analyse (Differential Power Analy- sis DPA), ist nicht auszuschließen. Aus der bisher beschriebenen Konstruktion lässt sich also die folgende Fragestellung ableiten: wie verhalten sich die gewünschten Eigenschaften des Gesamtprotokolls, wenn ein Teil der Geheimnisse bekannt wird (hier: Verlust einer der Schlüssel Kauth bzw. Kmac), z.B. durch Sei- tenkanalangriffe? Im bisher vorgeschlagenen Protokoll führt ein solcher Bruch eines Teilprotokolls zum Bruch des Gesamtprotokolls. Für das bisher vorgestellte Sicherheitskonzept wäre eine sogenannte Session Splitting Attack möglich, eine Attacke, welche unter Ausnutzung des Bruches einer der geheimen Schlüssel das gesamte Sicherheitskonzept aushebelt. Dabei kann der Angreifer z.B. nach Bruch des Integritätsschutzes (Kmac bekannt) die Transaktion (d.h. die Sitzung) aufteilen: er berechnet die Werte für den Integritätsschutz für von ihm gewählte Daten selbst (da Kmac bekannt) und benutzt die Originalquelle, um das Challen- ge-Response Protokoll erfolgreich zu absolvieren.
SCAs ließen sich beispielsweise erschweren, indem die minimal zulässige Zeit zwischen zwei Teilprotokollabläufen erhöht wird. Dies hat eine Senkung der möglichen Samplerate während des Angriffs zur Folge und erhöht somit den Zeitauf- wand für einen erfolgreichen Angriff. Während einer Erhöhung dieses minimalen Zeitraums beim Teilprotokoll Integritätssicherung enge Grenzen durch die benötigte Datenrate gesetzt sind, kann bei der Authentisierung ein sehr viel höherer Wert verwendet werden.
Das im folgenden beschriebene Konzept stellt eine effektive und effiziente Maßnahme gegen den Bruch des Gesamtprotokolls bei erfolgreichen Session- Splitting- Attacken (z. B. S CA- Angriffen) gegen ein Teilprotokoll dar. Es wird dabei in Abwandlung des bisher beschriebenen Protokolls vorgeschlagen, die beide Teilprotokolle so miteinander zu verbinden, dass z. B. die Kenntnis von Kmac (z. B. durch SCA, die hier schwerer verhindert werden können als beim anderen Teilprotokoll) keinen Bruch des Gesamtprotokolls nach sich zieht. Die vorgeschlagene Änderung erhält die positiven Eigenschaften des ursprünglichen Protokolls bezüglich Ressourcen und Sicherheit. Grundlage der vorgeschlagenen Variante ist die sichere Ableitung eines geheimen Wertes aus der Challenge und aus Kauth- Dieser Wert dient dann als Initialwert Ra0 des Nonces (number only used once) Ra, welches in jede MAC-Berechnung eingeht. Im Originalprotokoll (DE-102009002396) wird dieser Initialwert direkt aus der Challenge gebildet, einem dem Angreifer bekannten Wert.
Figur 6, bzw. Figuren 6a und 6b, zeigen eine schematische Darstellung zur Erläuterung eines Gesamtprotokolls einer Verbindung von Integritätsschutz und Authentifizierung zur Transaktionssicherheit der Sensordaten in der neu vorgeschlagenen Variante. Dabei ist die Kommunikation des Sensors A mit dem Steuergerät B dargestellt. Die Sensordaten des Sensors A an das Steuergerät B sind mit x bezeichnet. Der Sensor A und das Steuergerät B verfügen über einen gemeinsamen Schlüssel KAB, Auth, z. B. einen 128 bit AES-Schlüssel, für die Authentifizierung sowie über einen gemeinsamen Schlüssel KAB,MAC, Z. B.
wiederum einen 128 bit AES-Schlüssel, für den Message Authentication Code CMAC (im alternativen Fall des Message Authentication Code EMAC wären es zwei Schlüssel KAB,MACI und KAB,MAC2) -
Figur 6a zeigt erste Schritte des Sicherheitsgesamtkonzepts, genauer die Beschreibung eines Challenge- Response- Verfahrens. In einem ersten Schritt erzeugt das Steuergerät B eine kryptographisch sichere 64 bit Zufallszahl RB und sendet diese konkateniert mit der Identität I DB an den Sensor A: B -> A: RB II I DB. Der Sensor A verschlüsselt mit einem symmetrischen AES-Schlüssel KAB,Auth das empfangene Datenpaket (RB I I I DB). Von dem entstehenden Ergebnis
EncKAB,Auth(Rß I I I DB) der Länge 128 bit werden die 64 msb (most significant bits) genommen und zusammen mit der Identität I DA an das Steuergerät B
zurückgesendet: A -> B : msbi27...64 [EncK AB,Auth (RB II I DB)] I I I DA.
Gleich nachdem die Daten RB I I I DB an den Sensor geschickt wurden, kann das Steuergerät B seinerseits damit beginnen msbi27...64 [EncK AB,Auth(RB I I I DB)] zu berechnen. Es vergleicht dann die empfangenen Daten, sowohl msbi27...64 [EncK AB.Auth (RB II I DB)] als auch I DA. Nur im Fall, das je beide Werte übereinstimmen, wird das Protokoll fortgesetzt, der Sensor ist gegenüber dem Steuergerät authentifiziert. Im Fall, dass nur ein Wert abweicht, wird eine Fehlermeldung "Authentication of sensor failed" generiert.
Figur 6b zeigt die Verknüpfung von Authentifizierung und Integritätsschutz unter Ableitung des Initialwertes Rao der Nonce (number only used once) Ra aus der Challenge und aus Kauth-
Wie in Figur 6a zu sehen, wird Rb zusammen mit I Db im Sensor bereits verschlüsselt, um die Authentifizierungsantwort auszurechnen. Als Response im Challenge- Response- Verfahren der Authentifizierung wird übertragen res := MSB64 (Enc Kauth ( Rb || I Db)); die letzten 8 Bytes werden durch Trunkierung geheim gehalten. Das initiale Ra (Ra0) wird nun aus EncK AB,Auth (RB II I DB) abgeleitet, z.B. als LSB64 ( Enc Kauth (Rb II I Db), es wird also z. B. der in der Challenge- Response trunkierte Teil von Enc Kauth (Rb II I Db) (statt eines Teiles von Rb wie in der DE-102009002396) als Ra herangezogen. Der Sensor speichert also z. B. wie in Figur 6b gezeigt die 64 least significant bits (Isb) von EncK AB,Auth (RB II I DB) I I I DA als RA, bzw. als Initialwert Ra0 der Nonce RA ab.
Aus Gründen der Effizienz wird also ein bereits berechneter Teil aus dem Challenge- Response- Verfahren der Authentifizierung, z.B. der Teil, welcher nicht versendet wurde (response truncation / Anwort-Trunkierung), als Initialwert Ra0 verwendet. Die Sensordaten sind wie beschrieben mit x bezeichnet. Im
Folgenden können verschiedene Möglichkeiten zur Berechnung eines Message Authentication Codes, z.B. EMAC bzw. CMAC eingesetzt werden, wie oben beschrieben. Die Sensordaten x, konkateniert mit zeitvarianten Parametern, werden zusammen den msb64 des Message Authentication Codes MACKMac an das Steuergerät gesendet, siehe Figur 6b. Im Originalprotokoll werden die zeitvarianten Parameter, bzw. die aktuelle Nonce unverschlüsselt übertragen. Dies ist im geänderten, hier vorgeschlagenen Protokoll jedoch nicht mehr möglich, da dies die Antwort-Trunkierung (response truncation) der Authentifizierung schwächen würde. Um die Antwort-Trunkierung nicht zu schwächen, wird in einer bevorzugten Ausgestaltung zusätzlich statt der Ra nun der Wert c als unsigned integer mit Überlauf, mit c:= Ra-Rao übertragen und weiterhin Ra in der MAC- Berechnung verwendet, siehe Figur 6b:
A -> B: x II Isb32(c) || msb64 (MACKmac (x II RA)).
Abschließend wird der Sequence Counter RA um Eins erhöht.
Das Steuergerät B erhält die Sensordaten x und verarbeitet diese und / oder gibt diese weiter. Mit den empfangenen Daten wird nun auf Seite des Steuergerätes seinerseits der MAC-Wert berechnet und mit dem empfangenen MAC-Wert verglichen. Da dem Steuergerät der Ausgangswert für c, bzw. RA bekannt ist, kann es überprüfen, ob der gesendete Sequence Counter c innerhalb eines vorgegebenen Intervalles liegt. Falls ja, akzeptiert es den und führt obige
Berechnungen durch. Falls nein, 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 c, bzw. Ra. Nach der MAC-Berechnung und Vergleich wird c, bzw. RA um Eins inkrementiert.
Allgemeiner kann man formulieren, dass für eine Berechnung der zeitvarianten Parameter, welche im Rahmen der Transaktionsauthentifizierung, bzw. des Sensordaten-Integritätsschutzes verwendet werden, zumindest ein zweiter Teil der kryptographischen Authentifizierungsnachricht und für eine Berechnung des kryptographischen Integritätsschutzes zumindest ein dritter Teil der kryptographischen Authentifizierungsnachricht herangezogen wird, während im Rahmen der Sensorauthentifizierung ein erster Teil der kryptographischen Authentifizierungsnachricht MSB64 EncKAB, Auth(RB || IDB) versendet wurde. In dem in Figur 6 gezeigten Beispiel entspricht dem zweiten und dem dritten Teil LSB64 EncKAB, Auth(RB || IDB). Der zweite und der dritte Teil müssen dabei allerdings nicht identisch sein. Es kann vorteilhaft sein, wenn sich der erste Teil nicht mit dem zweiten und dem dritten Teil überschneidet oder zumindest nicht mit diesen identisch ist. Der zweite und dritte Teil können identisch sein, sich überschneiden oder getrennte Teile von EncKAB, Auth(RB || IDB) darstellen.
Der aktuelle Parameter Ra wird bei jeder Sensordaten-Transaktion berechnet, die zeitvarianten Parameter c entsprechen bei jeder Sensordaten-Transaktion der Differenz aus den initialen Wert Ra0, also im Beispiel LSB64 EncKAB, Auth(RB || IDB), und dem aktuellen Parameter der vorherigen Sensordatentransaktion.
Zu dem vorgestellten Ausführungsbeispiel des erfindungsgemäßen
Sicherheitsgesamtkonzepts gibt es Alternativen.
In jedem Schritt der Transaktionsauthentifizierung wird im oben vorgestellten Ausführungsbeispiel RA um 1 inkrementiert. 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
Transaktions-Authentifizierung, sind lediglich beispielhaft und lassen sich auch durch andere in der Beschreibung genannte Alternativ- Verfahren oder auch nicht genannte, vergleichbare Methoden ersetzen.
Die Zahl RB wurde im vorgestellten Konzept Zufallszahl genannt. Allgemeiner ist sie auch als Nonce (Number only used once - einmalig verwendete Zahl) vorsehbar, z.B. neben Zufallszahl auch als Zeitstempel oder Sequenzzähler.

Claims

Ansprüche
1. Verfahren zu einem Manipulationsschutz von Sensordaten (x) eines Sensors (A), wobei im Rahmen einer Authentifizierung des Sensors (A) eine einmalig verwendete Zahl (RB) von einem Steuergerät (B) an den Sensor (A) geschickt wird und der Sensor (A) eine kryptographische Authentifizierungsnachricht unter Verwendung der einmalig verwendeten Zahl (RB) generiert und zumindest einen ersten Teil der kryptographischen Authentifizierungsnachricht an das Steuergerät (B) sendet, wobei die Sensordaten (x) mit einem kryptographischen Integritätsschutz versehen werden, den Sensordaten (x) zeit- variante Parameter (c) hinzugefügt werden und wobei die Sensordaten (x) mit dem kryptographischen Integritätsschutz und den hinzugefügten zeitvarianten Parametern (c) von dem Sensor (A) an das Steuergerät (B) geschickt werden, gekennzeichnet dadurch, dass für eine Berechnung der zeitvarianten Parameter (c) zumindest ein zweiter Teil der kryptographischen Authentifizierungsnachricht und für eine Berechnung des kryptographischen Integritätsschutzes zumindest ein dritter Teil der kryptographischen Authentifizierungsnachricht herangezogen wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die zeitvarianten Parameter (c) bei jeder Sensordaten-Transaktion verändert werden.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Veränderung der zeitvarianten Parameter (c) einer schrittweisen Inkrementierung entspricht.
4. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass ein aktueller Parameter (Ra) aus dem zweiten Teil (Ra0) der kryptographischen Authentifizierungsnachricht bei jeder Sensordaten-Transaktion berechnet wird und dass die zeitvarianten Parameter (c) für eine n-ten Sensordaten-Transaktion aus einer Differenz des aktuellen Parameters (Ra) und des zweiten Teils (Ra0) der kryptographischen Authentifizierungsnachricht berechnet werden.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass der aktuelle Parameter (Ra) für die Berechnung des kryptographischen Integritätsschutzes herangezogen wird.
6. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Authentifizierung des Sensors (A) nach einem Challenge- Response-Verfahren durchgeführt wird.
7. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der kryptographische Integritätsschutz der Sensordaten (x) nach einem Message-Authentication-Code-(MAC)-Verfahren durchgeführt wird.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass als das MAC- Verfahren ein OMAC- oder ein EMAC-Verfahren verwendet wird.
9. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die zeitvarianten Parameter (c) durch Zeitstempel oder Sequenzzähler oder Zufallszahlen verändert werden.
10. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass sich der erste Teil der kryptographischen Authentifizierungsnachricht und der zweite Teil der kryptographischen Authentifizierungsnachricht nicht überschneiden und dass sich der erste der kryptographischen Authentifizierungsnachricht und der dritte Teil der kryptographischen Authentifizierungsnachricht nicht überschneiden.
11. Sensor (A), welcher Mittel aufweist, im Rahmen einer Authentifizierung des Sensors (A) eine einmalig verwendete Zahl (RB) von einem Steuergerät (B) zu empfangen, eine kryptographische Authentifizierungsnachricht unter Verwendung der einmalig verwendeten Zahl (RB) zu generieren und zumindest einen ersten Teil der kryptographischen Authentifizierungsnachricht an das Steuergerät (B) zu senden, sowie Mittel aufweist, die Sensordaten (x) mit ei- nem kryptographischen Integritätsschutz zu versehen, den Sensordaten (x) zeitvariante Parameter (c) hinzuzufügen und die Sensordaten (x) mit dem kryptographischen Integritätsschutz und den hinzugefügten zeitvarianten Parametern (c) von dem Sensor (A) an das Steuergerät (B) zu schicken, gekennzeichnet dadurch, dass der Sensor (A) Mittel aufweist, für eine Berechnung der zeitvarianten Parameter (c) zumindest einen zweiten Teil der kryptographischen Authentifizie- rungsnachricht und für eine Berechnung des kryptographischen Integritätsschutzes zumindest einen dritten Teil der kryptographischen Authentifizie- rungsnachricht heranzuziehen.
12. Sensor (A) nach Anspruch 11, dadurch gekennzeichnet, dass der Sensor (A) Mittel aufweist, die zeitvarianten Parameter (c) bei jeder Sensordaten- Transaktion zu verändern.
13. Sensor (A) nach Anspruch 12, dadurch gekennzeichnet, dass die Veränderung der zeitvarianten Parameter (c) einer schrittweisen Inkrementierung entspricht.
14. Sensor (A) nach Anspruch 12, dadurch gekennzeichnet, dass ein aktueller Parameter (Ra) aus dem zweiten Teil (Ra0) der kryptographischen Authentifi- zierungsnachricht bei jeder Sensordaten-Transaktion berechnet wird und dass die zeitvarianten Parameter (c) für eine n-ten Sensordaten-Transaktion aus einer Differenz des aktuellen Parameters (Ra) und des zweiten Teils (Ra0) der kryptographischen Authentifizierungsnachricht berechnet werden.
15. Steuergerät (B), welches Mittel aufweist, im Rahmen einer Authentifizierung eines Sensors (A) eine einmalig verwendete Zahl (RB) zu generieren und an den Sensor (A) zu senden, von dem Sensor (A) zumindest einen ersten Teil einer unter Verwendung der einmalig verwendeten Zahl (RB) generierten kryptographischen Authentifizierungsnachricht zu empfangen, eine kryp- tographische Vergleichs-Authentifizierungs-nachricht selbst zu generieren und den empfangenen ersten Teil der kryptographischen Authentifizierungsnachricht mithilfe der selbst generierten kryptographischen Vergleichs- Authentifizierungsnachricht auszuwerten, sowie Mittel aufweist, die mit einem kryptographischen Integritätsschutz und zeitvarianten Parametern (c) versehenen Sensordaten (x) auszuwerten, gekennzeichnet dadurch, dass das Steuergerät (B) Mittel aufweist, für eine Auswertung der zeitvarianten Parameter (c) zumindest einen zweiten Teil der selbst generierten kryptographischen Vergleichs-Authentifizierungsnachricht und für eine Auswertung des kryptographischen Integritätsschutzes zumindest einen dritten Teil der selbst generierten kryptographischen Vergleichs-Authentifizierungsnachricht heranzuziehen.
PCT/EP2010/063168 2009-09-29 2010-09-08 Verfahren zum manipulationsschutz von sensordaten und sensor hierzu WO2011039037A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201080043299.9A CN102577228B (zh) 2009-09-29 2010-09-08 用于传感器数据的操纵保护的方法和用于此的传感器
IN473DEN2012 IN2012DN00473A (de) 2009-09-29 2010-09-08
EP10754456.1A EP2484047B1 (de) 2009-09-29 2010-09-08 Verfahren zum manipulationsschutz von sensordaten und sensor hierzu
US13/498,954 US9100193B2 (en) 2009-09-29 2010-09-08 Method for protecting sensor data from manipulation and sensor to that end
JP2012531314A JP5584767B2 (ja) 2009-09-29 2010-09-08 センサデータの操作を防止するための方法及びこのためのセンサ

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102009045133.1 2009-09-29
DE102009045133A DE102009045133A1 (de) 2009-09-29 2009-09-29 Verfahren zum Manipulationsschutz von Sensordaten und Sensor hierzu

Publications (1)

Publication Number Publication Date
WO2011039037A1 true WO2011039037A1 (de) 2011-04-07

Family

ID=43221947

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/063168 WO2011039037A1 (de) 2009-09-29 2010-09-08 Verfahren zum manipulationsschutz von sensordaten und sensor hierzu

Country Status (7)

Country Link
US (1) US9100193B2 (de)
EP (1) EP2484047B1 (de)
JP (1) JP5584767B2 (de)
CN (1) CN102577228B (de)
DE (1) DE102009045133A1 (de)
IN (1) IN2012DN00473A (de)
WO (1) WO2011039037A1 (de)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009002396A1 (de) * 2009-04-15 2010-10-21 Robert Bosch Gmbh Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu
DE102013206202A1 (de) * 2013-04-09 2014-10-30 Robert Bosch Gmbh Sensormodul und Verfahren zum Betreiben eines Sensorsmoduls
DE102013218212A1 (de) * 2013-09-11 2015-03-12 Robert Bosch Gmbh Verfahren zum abgesicherten Übermitteln von Daten
JP6126980B2 (ja) 2013-12-12 2017-05-10 日立オートモティブシステムズ株式会社 ネットワーク装置およびネットワークシステム
JP2015122620A (ja) * 2013-12-24 2015-07-02 富士通セミコンダクター株式会社 認証システム、認証方法、認証装置、及び、被認証装置
DE102015207220A1 (de) 2014-04-28 2015-10-29 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
CN104079408B (zh) * 2014-05-30 2018-01-19 国家电网公司 一种工业控制系统中增强通信安全性的方法
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
JP2016131311A (ja) * 2015-01-14 2016-07-21 日本電信電話株式会社 ユーザ端末、サーバ装置、通信システム、通信方法、プログラム
EP3056706A1 (de) 2015-02-16 2016-08-17 Honeywell International Inc. Ansatz zur nachbehandlungssystemmodellierung und modellidentifizierung
DE102015202935A1 (de) * 2015-02-18 2016-08-18 Robert Bosch Gmbh Verfahren zum Manipulationsschutz
DE102015220038A1 (de) 2015-05-22 2016-11-24 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
DE102015209496A1 (de) 2015-05-22 2016-11-24 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
JP6361589B2 (ja) * 2015-06-11 2018-07-25 株式会社デンソー 通信システム
DE102015211451A1 (de) 2015-06-22 2017-01-05 Volkswagen Aktiengesellschaft Verfahren zu einem Manipulationsschutz von über ein Bussystem zwischen Systemkomponenten zu übertragenden Nutzdatenpaketen
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
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
DE102015220048A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren 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
DE102015220045A1 (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
DE102015220024A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
DE102015220026A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Verfahren zur Erzeugung eines Geheimnisses für eine Einmalverschlüsselung 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
DE102015220057A1 (de) 2015-10-15 2017-04-20 Robert Bosch Gmbh Schaltungsanordnung zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
US10230756B2 (en) 2015-11-25 2019-03-12 International Business Machines Corporation Resisting replay attacks efficiently in a permissioned and privacy-preserving blockchain network
DE102016103498A1 (de) * 2016-02-26 2017-08-31 Infineon Technologies Ag Ein Verfahren zum Übermitteln von Daten von einem Sensorbauelement an eine elektronische Steuereinheit, ein Sensorbauelement und eine elektronische Steuereinheit
US10124750B2 (en) 2016-04-26 2018-11-13 Honeywell International Inc. Vehicle security module system
US10728249B2 (en) 2016-04-26 2020-07-28 Garrett Transporation I Inc. Approach for securing a vehicle access port
US10036338B2 (en) 2016-04-26 2018-07-31 Honeywell International Inc. Condition-based powertrain control system
US10630481B2 (en) * 2016-11-07 2020-04-21 Ford Global Technologies, Llc Controller area network message authentication
EP3548729B1 (de) 2016-11-29 2023-02-22 Garrett Transportation I Inc. Inferenzflusssensor
KR101966088B1 (ko) * 2017-04-06 2019-04-05 상명대학교산학협력단 Iot 응용에 최적화된 인증 암호 장치 및 방법
JP6818623B2 (ja) * 2017-04-27 2021-01-20 株式会社東芝 情報処理装置
WO2019026833A1 (ja) * 2017-08-04 2019-02-07 日本電産株式会社 認証システム、当該認証システムにおいて用いられる電子機器および認証方法
US11057213B2 (en) 2017-10-13 2021-07-06 Garrett Transportation I, Inc. Authentication system for electronic control unit on a bus
JP7119537B2 (ja) * 2018-04-24 2022-08-17 日本電信電話株式会社 検知システムおよび検知方法
CN108833346A (zh) * 2018-05-04 2018-11-16 北京天元创新科技有限公司 一种工业控制系统安全通信方法和装置
CN110351095B (zh) * 2019-07-12 2022-06-07 四川虹美智能科技有限公司 一种控制多联式空调机组运行的方法和装置
JP7325318B2 (ja) * 2019-12-17 2023-08-14 株式会社日立製作所 証跡記録システム及びデータ検証方法
CN111786797B (zh) * 2020-07-03 2022-10-18 四川阵风科技有限公司 三方通信的时效性验证方法
US20220103354A1 (en) * 2020-09-25 2022-03-31 Renesas Electronics Corporation Secure encryption key generation and management in open and secure processor environments

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007088288A1 (fr) * 2006-02-03 2007-08-09 Advanced Track & Trace Procede et dispositif d'authentification
US20080263647A1 (en) * 2006-07-21 2008-10-23 General Electric Company System and Method For Providing Network Device Authentication
DE102009002396A1 (de) 2009-04-15 2010-10-21 Robert Bosch Gmbh Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4198509B2 (ja) * 2003-04-14 2008-12-17 日本電信電話株式会社 相互認証方法
DE10318031A1 (de) 2003-04-19 2004-11-04 Daimlerchrysler Ag Verfahren zur Sicherstellung der Integrität und Authentizität von Flashware für Steuergeräte
JP4665465B2 (ja) 2004-09-07 2011-04-06 パナソニック株式会社 通信装置、通信システム、通信方法
CN101116281A (zh) * 2005-02-10 2008-01-30 国际商业机器公司 询问-应答签名和安全迪菲-海尔曼协议
JP2006270348A (ja) * 2005-03-23 2006-10-05 Victor Co Of Japan Ltd 相互認証及び鍵共有システム
JP4735644B2 (ja) 2005-11-04 2011-07-27 日本電気株式会社 メッセージ認証装置、メッセージ認証方法、メッセージ認証プログラムとその記録媒体
JP4810289B2 (ja) * 2006-04-17 2011-11-09 ルネサスエレクトロニクス株式会社 メッセージ認証子生成装置、メッセージ認証子検証装置、及びメッセージ認証システム
US8102999B2 (en) * 2006-08-18 2012-01-24 Medtronic, Inc. Secure telemetric link
US7957533B2 (en) * 2007-10-02 2011-06-07 Alcatel-Lucent Usa Inc. Method of establishing authentication keys and secure wireless communication

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007088288A1 (fr) * 2006-02-03 2007-08-09 Advanced Track & Trace Procede et dispositif d'authentification
US20080263647A1 (en) * 2006-07-21 2008-10-23 General Electric Company System and Method For Providing Network Device Authentication
DE102009002396A1 (de) 2009-04-15 2010-10-21 Robert Bosch Gmbh Verfahren zum Manipulationsschutz eines Sensors und von Sensordaten des Sensors und einen Sensor hierzu

Non-Patent Citations (25)

* Cited by examiner, † Cited by third party
Title
"Bundesamt für Sicherheit in der Informationstechnik BSI, AIS 31: Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Anwendungshinweise und Interpretationen zum Schema (AIS)", BSI, vol. 1, 25 September 2001 (2001-09-25)
"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 9798-2, Information technology - Security techniques - Entity Authentication - Part 2: Mechanisms using symmetric encipherment algorithms", ISO/I EC, 1994
"ISO/IPC 9797, Information technology - Security techniques - Data integrity mechanisms using a cryptographic check function employing block cipher algorithm", ISO/1 EC, 1994
"ISO/IPC 9797, Information technology - Security techniques - Data integrity mechanisms using a cryptographic check function employing block cipher algorithm", ISO/I EC, 1994
A. BOGDANOV; L.R. KNUDSEN; G. LEANDER; C. PAAR; A. POSCHMANN; M.J.B. ROBSHAW; Y. SEURIN; C. VIKKELSOE: "Proceedings of CHES 2007, volume 4727 of Lecture Notes in Computer Science", vol. 4727, 2007, SPRINGER-VERLAG, article "An ultra-lightweight block cipher, in P. Pallier and 1", pages: 450 - 467
A. J. MENEZES; P. C. VAN OORSCHOT; S. A. VANSTONE: "Handbook of Applied Cryptography", 1996, CRC PRESS, pages: 334
A. J. MENEZES; P. C. VAN OORSCHOT; S. A. VANSTONE: "Handbook of Applied Cryptography", 1996, CRC PRESS, pages: 334 - 335
A. J. MENEZES; P. C. VAN OORSCHOT; S. A. VANSTONE: "Handbook of Applied Cryptography", 1996, CRC PRESS, pages: 362
ANDREY BOGDANOV; CHRISTOF PAAR: "On the Security and Efficiency of Real-World Lightweight Authentication Protocols, In Secure Component and System Identification", WORKSHOP RECORD OF SECSI, 17 March 2008 (2008-03-17)
COLIN BOYD; ANISH MATHURIA: "Protocols for Authentication and Key Establishment", 2003, SPRINGER, pages: 31
E. PETRANK; C. RACKOFF: "CBC MAC for real-time data sources", JOURNAL OF CRYPTOLOGY, vol. 3, no. 13, 2000, pages 315 - 338
H. CAM ET AL: "Energy efficient security protocol for wireless sensor networks", VEHICULAR TECHNOLOGY CONFERENCE, 2003. VTC 2003-FALL. 2003 IEEE 58TH ORLANDO, FL, USA 6-9 OCT. 2003; [IEEE VEHICULAR TECHNOLGY CONFERENCE], PISCATAWAY, NJ, USA,IEEE, US, vol. 5, 6 October 2003 (2003-10-06), pages 2981 - 2984, XP010702162, ISBN: 978-0-7803-7954-1, DOI: DOI:10.1109/VETECF.2003.1286170 *
HENK C. A. VAN TILBORG,: "Encyclopedia of Cryptography and Security", 2005, SPRINGER, pages: 365
J. BLACK; P. ROGAWA: "Advances in Cryptology - CRYPTO 2000", 2000, SPRINGER-VERLAG, article "CBC MACs for arbitrary-length messages", pages: 197 - 215
JONATHAN KAHTZ; YEHUDA LINDELL: "Introduction to Modern Cryptography", 2007, CRC PUBLISHING, pages: 126
JONATHAN KAHTZ; YEHUDA LINDELL: "Introduction to Modern Cryptography", 2007, CRC PUBLISHING, pages: 16
M. BELLARE; J. KILIAN; F.:'ROGAWAY, THE SECURITY OF CIPHER BLOCK CHAINING, JOURNAL OF COMPUTER AND SYSTEM SCIENCES, vol. 3, no. 61, 2000, pages 362 - 399
M. BOHGE, W TRAPPE: "An authentication framework for hierarchical ad hoc sensor networks", WISE '03 PROCEEDINGS OF THE 2ND ACM WORKSHOP ON WIRELESS SECURITY, 19 September 2003 (2003-09-19), San Diego, CA, USA, pages 79 - 87, XP040167946, ISBN: 1-58113-769-9 *
MIHIR BELLARE, RAN CANETTI AND HUGO KRAWCZYK,: "Proceedings of CRYPTO '96", vol. 1109, 1996, SPRINGER, article "Mihir Bellare, Ran Canetti and Hugo Krawczyk, Keying hash functions for message authentication", pages: 1 - 15
MORRIS DWORKIN: "Cipher Modes of Operation: The CMAC Mode for Authentication", May 2005, NIST SPECIAL PUBLICATION 800-38B
T. IWATA; K. KUROSAWA: "OMAC: One key CBC MAC", 2003, SPRINGER-VERLAG, pages: 129 - 153
W. KILLMANN; W. SCHINDLER: "Ein Vorschlag zu: Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Technisches", PAPIER ZU AIS 31, vol. 3.1, 25 September 2001 (2001-09-25), Retrieved from the Internet <URL:http://www.bsi.bund.de/zertifiz/zert/interpr/trngkr31.pdf>
WALTER FUMY; HANS-PETER RIESS; KRYPTOGRAPHIE, ENTWURF: "Einsatz und Analyse symmetrischer Kryptoverfahren, second edition,", 1994, VERLAG

Also Published As

Publication number Publication date
JP5584767B2 (ja) 2014-09-03
EP2484047B1 (de) 2016-03-23
CN102577228A (zh) 2012-07-11
US9100193B2 (en) 2015-08-04
DE102009045133A1 (de) 2011-03-31
IN2012DN00473A (de) 2015-06-05
JP2013506369A (ja) 2013-02-21
CN102577228B (zh) 2015-01-07
US20120303973A1 (en) 2012-11-29
EP2484047A1 (de) 2012-08-08

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
DE102010002241B4 (de) Vorrichtung und Verfahren zur effizienten einseitigen Authentifizierung
DE102013206185A1 (de) Verfahren zur Erkennung einer Manipulation eines Sensors und/oder von Sensordaten des Sensors
DE60029391T2 (de) Verschlüsselung mittels öffentlichem Schlüssel mit einem digitalen Unterschriftsverfahren
DE102011120968B4 (de) Erzeugen von sicheren Schlüsseln auf Anforderung
US7715553B2 (en) Encrypting a plaintext message with authentication
DE102011011652B4 (de) Verfahren zum Verwenden eines ECDSA mit Winternitzeinmalsignatur
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
EP1278332B1 (de) Verfahren und System zur Echtzeitaufzeichnung mit Sicherheitsmodul
EP3304802B1 (de) Verfahren zur sicherstellung der informationssicherheit von über einen datenbus übertragenen daten sowie datenbussystem
EP1125395A1 (de) Verfahren und anordnung zur authentifikation von einer ersten instanz und einer zweiten instanz
DE112012000971B4 (de) Datenverschlüsselung
EP3506144A1 (de) Verfahren und system zum überprüfen einer integrität einer kommunikation
Alomair et al. E-MACs: Toward more secure and more efficient constructions of secure channels
CH708240A2 (de) Signaturprotokoll und Gerät zu dessen Umsetzung.
WO2020201010A1 (de) Vorrichtungen und verfahren zum erzeugen und zur authentisierungsprüfung mindestens eines in einem bus-system (bu) insbesondere eines kraftfahrzeugs zu übertragenden datenpakets
EP3206154B1 (de) Verfahren und vorrichtungen zum sicheren übermitteln von nutzdaten
DE60133140T2 (de) System und verfahren für symmetrische kryptographie
DE102023115999A1 (de) Verfahren, Vorrichtung, System und Computerprogrammprodukt zur PQ-sicheren Aktualisierung einer Datenverarbeitungseinheit
DE102019216203A1 (de) Auf Blockverschlüsselung basierender Proof-of-Work
DE102008010787B4 (de) Verfahren zur Sicherung der Integrität von Daten
EP4268412A1 (de) Verfahren zur verschlüsselung eines klartextes

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080043299.9

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2010754456

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10754456

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 473/DELNP/2012

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2012531314

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 13498954

Country of ref document: US