Data transmitter with a secure and efficient signature

An encryption device encrypts a first block of user data to obtain a first encryption result and encrypts a second block of user data, which follows the first block of user data, to obtain a second encryption result. The encryption device uses the first encryption result for encrypting the second block of user data. An extractor extracts a first portion of the first encryption result, the first portion being smaller than the first encryption result, and a second portion of the second encryption result, the second portion being smaller than the second encryption result. A message formatter combines the first block of user data and the first portion as a signature for the first block to produce a first transmission packet, and combines the second block of user data and the second portion as a signature for the second block to produce a second transmission packet.

PRIORITY CLAIM

This application claims priority to German Patent Application No. 10 2010 042 539.7 filed on 15 Oct. 2010, the content of said application incorporated herein by reference in its entirety.

TECHNICAL FIELD

Exemplary embodiments of the present invention relate to a data transmitter, particularly a data transmitter which transmits successive blocks of user data with a secure but efficient signature.

BACKGROUND

The communication protocols used in the automotive industry for the communication between sensors and controllers contain no precautions against the manipulation of the transmitted data by hackers. These attacks include tuning engines and breaking engine immobilizers, for example. Engine tuning can result in significant financial damage on the part of the automotive manufacturer, for example. In addition, for electric road vehicles (E-car) and the networking thereof, the authentication of the communication partners, e.g. the authentication between sensors and controllers, and the protection of the integrity of the transmitted data may assume a high level of significance in the future.

In the automotive industry, both unidirectional and bidirectional protocols are used for networking sensors and controllers, for example. Known protocols in the automotive industry are the SENT protocol (SENT=single edge nibble transmission) and the PSI5 protocol (PSI5=peripheral sensor interface 5, a digital interface for sensors), for example. The SENT protocol is a unidirectional protocol which is standardized in the SAE J2716 standard and can be used as a digital sensor interface, e.g. for connecting engine pressure sensors or Hall sensors, which detect valves or pedal positions, for example, to the ECU (ECU=engine control unit, engine controller). The PSI5 protocol is a bidirectional protocol which can be used for connecting airbag sensors, for example.

Usually, the known protocols used in the automotive industry have CRC protection (CRC=cyclic redundancy check) in order to detect transmission errors which may arise particularly in the engine surroundings, which have a high level of electromagnetic noise. However, the known protocols used in the automotive industry have no protection for the transmitted data against malicious attacks, e.g. by hackers. By way of example, a hacker could manipulate the transmitted data for a pressure sensor in order to use manipulated or corrupted data at the input of the engine controller to manipulate the data at the output of the engine controller, which can achieve a power increase for the engine (tuning the engine), for example. However, as already mentioned, the CRC protection of the known protocols used in the automotive industry does not protect the transmitted data against the manipulation, since the correct CRC bits can easily be calculated for the corrupted data.

The standardized protocols in the automotive sector, which, in addition to the SENT and PSI5 protocols, also include the protocols SEC, CAN (CAN=controller area network, an ISO standard protocol for automotive applications) and FlexRay (a serial, deterministic and error-tolerant field bus system for use in automobiles), cannot be extended by the known measures for protecting integrity. By way of example, appending an MAC (MAC=message authentication code) to the data in a transmitted protocol frame or else transmitting an entire MAC in a suitable frame subsequent to the data is not possible, firstly because the protocol frames can no longer be extended—for reasons of compatibility—to the extent required by the known measures for protecting integrity, and secondly because the realtime capability means that it is not possible to transmit or insert any additional frames to this required extent.

SUMMARY

Embodiments described herein provide secure but efficient communication between a data transmitter and a data receiver.

In one embodiment, a data transmitter is provided for transmitting successive blocks of user data which is operable to encrypt a first block of user data in order to obtain a first encryption result and to encrypt a second block of user data using a portion of the first encryption result in order to obtain a second encryption result. The data transmitter is operable to use a portion of the first encryption result, which portion is smaller than the first encryption result, as a signature for the first block of user data and to use a portion of the second encryption result, which portion is smaller than the second encryption result, as a signature for the second block of user data and to produce a first transmission packet which has the first block of user data and the first signature and to produce a second transmission packet which has the second block of user data and the second signature.

In another embodiment, a data receiver is provided for receiving the first transmission packet and the second transmission packet. The first and second received transmission packets each have a received block of user data and a received signature. The data receiver is operable to encrypt the first received block of user data in order to obtain a first encryption result and to encrypt the second received block of user data using the first encryption result in order to obtain a second encryption result. The data receiver is operable to use a portion of the first encryption result, which portion is smaller than the first encryption result, as a reference signature for the first received block of user data and to use a portion of the second encryption result, which portion is smaller than the second encryption result, as a reference signature for the second block of user data. The data receiver is operable such that for a valid first received transmission packet the first reference signature is the same as the received signature from the first received block of user data, and that for a valid second received transmission packet the second reference signature is the same as the received signature from the second received block of user data.

DETAILED DESCRIPTION

In the description of the exemplary embodiments which follows, elements which are the same or which have the same effect are provided with the same reference symbols in the figures.

FIG. 1shows an embodiment of a data transmitter100for transmitting successive blocks of user data Bi. An encryption device104is operable to encrypt a first block of user data B1in order to obtain a first encryption result VE1and to encrypt a second block of user data B2, which follows the first block of user data B1, in order to obtain a second encryption result VE2. The encryption device104is also operable to use the first encryption result VE1for encrypting the second block of user data B2. To this end, the data transmitter100may have a delay device106, for example, which is operable to store the prior encryption result VEi−1from the prior block of user data Bi−1and to output it after a delay in order to provide the stored prior encryption result VEi−1to the encryption device104for encrypting the subsequent block of user data Biin order to obtain the encryption result Vie. Thus, by way of example, the third encryption result VE3from the third block of user data B3can be stored by the delay device106and output after a delay, so that the encryption device104can use the third encryption result VE3for encrypting the fourth block of user data B4in order to obtain the fourth encryption result VE4.

The data transmitter100also has an extractor108which is operable to extract a portion of the encryption result VEi, herein the extracted portion of the encryption result VEiis smaller than the encryption result VEi. The extractor108may also be operable to output the extracted portion of the encryption result VEias a signature Sifor the block of user data Bi. Thus, the extractor108is able, for example, to extract a portion of the first encryption result VE1, which portion is smaller than the first encryption result VE1, and to output this portion as a signature S1for the first block of user data B1, and to extract a portion of the second encryption result VE2, which portion is smaller than the second encryption result VE2, and to output this portion as a signature S2for the second block of user data B2.

Furthermore, the data transmitter100has a message formatter110for combining the block of user data Biand the signature Siin order to produce a transmission packet BiSi. Hence, the message formatter100is able, by way of example, to combine the first block of user data B1with the extracted portion of the first encryption result VE1as a signature S1in order to produce a first transmission packet B1S1and to combine the second block of user data B2with the extracted portion of the second encryption result VE2as a signature S2in order to produce a second transmission packet B2S2.

The data transmitter100therefore produces a secure but efficient signature Sifor each block of user data Bi, wherein each block of user data Biis transmitted with the relevant signature Sias a transmission packet BiSi. The signature Siis firstly efficient, since only a portion of the respective encryption result VEiis used as a signature Si, and secondly secure, since the block of user data Biis encrypted using the prior encryption result VEi−1from the prior block of user data Bi−1. If the extracted portion of the encryption result VEicomprises one bit, for example, and the signature therefore has only this one bit, the probability P of manipulation of the block of user data Biremaining unnoticed would be P=2−N, where N is the number of transmitted blocks of user data Bi.

After twelve transmitted blocks of user data Bi, for example, only one attack from 4,096 attacks would remain unnoticed. The probability of recognizing manipulation of the blocks of user data Biincreases with the number N of transmitted transmission packets BiSi. For this reason, it is possible to encrypt ten or more blocks of user data Biwhich follow the second block of user data B2in order to obtain further encryption results, wherein each further block of user data Biis encrypted on the basis of a prior encryption result VEi. Furthermore, the extracted portion of the encryption result VEi, which portion is used as a signature Si, may be naturally longer than 1 bit, wherein for an efficient signature Sithe number N of extracted bits needs to be chosen such that the extracted portion of the encryption result VEiis less than ⅛ of the bits of the encryption result VEi.

Furthermore, the data transmitter100may have an optional challenge/response device112, e.g. for performing a challenge/response check, and/or an optional resynchronization device114, e.g. for resetting the encryption device. The precise description of the challenge/response device112and of the resynchronization device114is given in the description ofFIGS. 5 and 6, for which reason a detailed description is dispensed with at this junction.

FIG. 2shows an embodiment of a data receiver120for receiving successive transmission packets Bi′Si′. The data receiver120has a reception device122for receiving transmission packets Bi′Si′, e.g. for receiving a first transmission packet B1′ and a second transmission packet B2′. Each transmission packet Bi′Si′ has a received block of user data Bi′ and a received signature Si′ for the received block of user data Bi′. Furthermore, the data receiver120has a message extractor124for extracting the received transmission packet Bi′Si′ in order to obtain the received block of user data Bi′ and the received signature Si′ for the received block of user data Bi′. Hence, by way of example, the first received block of user data B1′ and the first received signature Si′ and also the second received block of user data B2′ and the second received signature S2′ can be obtained.

In order to check the received signature Si, the data receiver120has an encryption device126, an extractor128and a comparison device130. The encryption device126is operable to encrypt a first received block of user data B1′ in order to obtain a first encryption result VE1* and to encrypt a second received block of user data B2′ in order to obtain a second encryption result VE2*. The encryption device126is also operable to use the first encryption result VE1* for encrypting the second received block of user data B2. To this end, the data receiver120may have a delay device132, for example, which is operable, for example, to store a prior encryption result VEi−1* for the prior block of user data Bi−1′ and to output it after a delay in order to provide the stored prior encryption result VEi−1* from the encryption device126for encrypting the subsequent block of user data Biin order to obtain the subsequent encryption result VEi*. Thus, for example, the fourth encryption result VE4* from the fourth received block of user data B4′ can be stored by the delay device132and output after a delay, so that the encryption device126can use the fourth encryption result VE4* for encrypting the fifth received block of user data B5′ in order to obtain the fifth encryption result VE5*.

The extractor128is operable to extract a portion of the encryption result VEi* in order to obtain a reference signature Si*. The encryption device126and the extractor128are operable so that for a valid transmission packet Bi′Si′ the reference signature Si* is the same as the received signature Sifrom the received block of user data Bi.

The data receiver120may also have an optional output device134which is operable to output the received block of user data Bi′ if the received signature Si′ from the received block of user data Bi′ is the same as the reference signature Si* and to reject the received block of user data Bi′ and trigger a resynchronization event if the received signature Si′ from the received block of user data Bi′ is not the same as the reference signature Si*. To this end, the data transmitter120may have a resynchronization device138, for example. The mode of operation of the resynchronization with a data transmitter100is described more precisely in the description forFIG. 6, as a result of which a detailed description of which is dispensed with at this juncture. Furthermore, the data receiver120may have an optional challenge/response device136, e.g. for performing a challenge/response check. The precise description of the challenge/response device136is likewise given in the description forFIG. 6, for which reason a detailed description is dispensed with at this juncture.

The data transmitter100and the data receiver120can be used for setting up bidirectional protocol, for example. The mode of operation of the data transmitter100and of the data receiver120will therefore be described by way of example below using an extension of the known SENT protocol. For alternative embodiments, the data transmitter100and the data receiver120are operable to operate using a bidirectional protocol, such as the PSI5 protocol.

FIG. 3shows a communication frame150from a relatively high protocol layer of the SENT protocol. From the point of view of the application layer, the communication frame150of the SENT protocol has 24 bits of user data152and 4 bits of status and control information which are combined in a status block (status nibble)154. The status block154has two unused bits. Of these two free bits, it is possible for one or two bits to be used for transmitting the signature Sior the integrity protection information, for example. InFIG. 3, the first bit of the status block154is used for transmitting the signature Si, for example. For a cryptographic extension of the SENT protocol, the i-th communication frame150is subsequently considered by way of example, the communication frame having a block of user data Biof the length m=24+3=27 bits and the signature Siof the length 1 bit. Before the start of the transmission of the transmission packets BiSifrom the data transmitter100to the data receiver120, it is possible to perform a challenge/response check, for example, in order to increase the protection for the blocks of user data Biagainst manipulation.

FIG. 4shows two required steps for setting up a secure connection between the data transmitter100and the data receiver120. The first step180comprises the authentication of the data transmitter120as a prerequisite for setting up a secure communication or connection. Furthermore, if necessary, the data transmitter100can be authenticated to the data receiver120, for example. To this end, the data transmitter100and/or the data receiver120may have a challenge/response device112or126, for example. In a second step182, if the authentication is successful, the data transmission or transmission of the transmission packets BiSibetween a data transmitter100, e.g. a sensor, and a data receiver120, e.g. the engine controller, can be started. If the authentication fails, the data transmitter100or the data receiver120can terminate the connection, for example, since it can be assumed that a hacker is attempting to manipulate or simulate the data transmitter100and/or the data receiver120, for example. By way of example, if the authentication fails, the engine control unit can assume that a hacker has manipulated the sensor, as a result of which trustworthy transmission packets BiSiare no longer being received. The data transmitter100and the data receiver120and also the first step180and the second step182therefore extend the known SENT protocol to produce a secure message protocol.

In the first step180, it is also possible to generate a secret key k and an encrypted version r of a random number R which is required for setting up a secure communication channel between the data transmitter100and the data receiver120and hence for the second step182of transmitting the transmission packets BiSi. The prerequisites for generating the secret key k and the encrypted version r of the random number R are presented below.

A first prerequisite for successful authentication and for the subsequent transmission of the transmission packets BiSiis that the data transmitter100and the data receiver120have a shared secret key kID. This shared secret key kIDmay have a length of 128 bits, for example. In addition, it is assumed that the keys can be regarded as independent and uniformly drawn random variables. Furthermore, the key is to be protected against reading in the data transmitter100and in the data receiver120and also during any logistical handling of the key. This means that the key needs to be protected against reading in any situation, e.g. during production, during the transmission of the key to the data transmitter100and to the data receiver120, or when a data transmitter100or a data receiver120is replaced and it is necessary to update the key.

A second prerequisite is that every data transmitter100and data receiver120has a dedicated and individual key. This means that one or more data transmitters100and/or data receivers120can never have the same key. This is a prerequisite in order to ensure that the entire system is not cracked when a hacker cracks a single key from a data transmitter100or from a data receiver120, for example. A single key cracked by the hacker therefore does not threaten the entire system, e.g. a plurality of sensors and controllers for a data bus in a motor vehicle.

A third prerequisite is that the data transmitter100and/or the data receiver120has/have a true random number generator (TRNG) or a cryptographically pseudo random number generator (PRNG). By way of example, it is subsequently possible for the generated random numbers to be used by the challenge/response device112or126of the data transmitter100or of the data receiver120to perform a challenge/response check. Furthermore, the challenge/response devices112and136of the data transmitter100and of the data receiver120may have a random number generator, for example, in order to generate the required random numbers themselves.

A fourth prerequisite is that the encryption device of the data transmitter100and of the data receiver120are operable to perform the same encryption. To this end, the encryption devices104and126may be operable, for example, to perform AES block encryption (AES=advanced encryption standard). For AES block encryption, it is possible to use 128-bit keys, for example, for encrypting 128-bit blocks of user data Bi. By contrast, a decryption device is not required. The AES block encryption can, depending on performance requirements, be implemented in hardware or software. Encryption with a key k is subsequently indicated by c=AES (key=k, d), where d is the unencrypted data and c is the encrypted data.

FIG. 5shows a two-way challenge/response check for authenticating the data transmitter100to the data receiver120. This challenge/response check therefore shows one aspect of the first step180of the authentication fromFIG. 4. R is the random challenge random number, and the challenge random number R has the length t. The length t of the challenge random number R should be no less than t=72 bits, where t can be regarded as a scalable security parameter which can be increased if required. In a first message190, the data receiver120sends the data transmitter100the random challenge random number R. Next, both the data transmitter100and the data receiver120use the shared secret key kIDto ascertain the encrypted version r=AES (key=kID, R) or r′=AES (key=kID, R) of the random number R. The data transmitter100is provided with the received encrypted version r′ of the random number R and the data receiver120is provided with the encrypted version r of the random number R. The data transmitter100then uses a second message192to send the data receiver120the encrypted version r′ of the random number R. The data receiver120, having received the second message, compares the encrypted version r′ of the random number R from the data transmitter100with its own encrypted version r of the random number R. If the two encrypted versions r′ and r of the random number R match (r′=r), the data transmitter100has authenticated itself to the data receiver120and the data receiver120therefore accepts the data transmitter100. If the two encrypted versions r′ and r of the random number R do not match (r′≠r), the authentication has failed and the data receiver120does not accept the data transmitter100.

Alternatively, it is possible to check the validity of the authentication by virtue of the data transmitter100changing directly to the data transmission phase instead of transmitting an encrypted version r′ of the random number R to the data receiver120in a second message192. In this case, the authentication can take place directly by means of the signature Si, for example.

After the first step180or the two-way challenge/response check, the data receiver120can be sure that the data transmitter100is an original data transmitter100, provided that the key has not been extracted from the data transmitter100and a hacker is not using the extracted key to simulate the data transmitter100. The random challenge/response check or a random challenge/response protocol prevents repeatable attacks, e.g. attacks which are based on the repetition of previously recorded sessions. Following the authentication, the data transmitter100and the data receiver120can use the shared information, the key kip and the encrypted version of the random number r or r′ in the second step182of the transmission of the transmission packets BiSi. In this case, the encrypted version r or r′ of the random number R may have a length of 128 bits, for example.

FIG. 6shows an aspect of an encryption device104and126for obtaining a secure but efficient signature Sifor successive blocks of user data Bi. In this case, the signature Siis obtained by first using a CBC-MAC design (CBC=Cipher Block Chaining), by way of example. The ⊕ symbol represents a combination between two input variables. By way of example, this combination can be effected by an XOR or XNOR addition, e.g. by an XOR or XNOR gate, with two 128-bit vectors being able to be used as input variables, for example. However, the CBC-MAC is not implemented in conventional fashion, i.e. an entire MAC is not transmitted after every transmitted block of user data Bi, but rather an incremental signature Siis generated by virtue of every encryption, e.g. an AES encryption, being followed by the extraction of a portion of the encryption result VEi, which portion is smaller than the encryption result VEi, and the appending of the portion to the unencrypted block of user data Biin order to obtain a transmission packet BiSi, wherein the prior encryption result VEiis used for encrypting the subsequent block of user data Bi+1. Using the SENT protocol, the extracted portion of the encryption result VEimay comprise 1 bit, for example, in which case the integrity protection information has a succession of bits S=Si, Si+1, Si+2, . . . , Si+N.

The blocks of user data Biare therefore transmitted in unencrypted form and can be observed by everyone, for example. The manipulation of the blocks of user data Biby a hacker is detected with a very high level of probability, however.

Particularly in the field of automotive sensor systems, it is sufficient for manipulation to be recognized with a delay after a series of transmitted transmission packets BiSi. However, the recognition must be assured with an extremely high level of certainty after a certain number of transmitted transmission packets BiSi, e.g. after 50-100 transmitted transmission packets BiSi. The data transmitter100and/or the data receiver120do exactly this and furthermore allow implementation in the existing transmission protocols, such as in SENT, SENT/SPC, SEC, PSI5, CAN or FlexRay, which means that costs for the implementation are minimal given a simultaneous high level of gained certainty.

InFIG. 6, the first block of user data B1can be encrypted using an initial vector IV, for example, which has a length of 128 bits, for example. For the initial vector IV, it is possible to use the encrypted version r of the random number R, for example, that is to say IV=r, for example. This ensures that the succession of calculated signatures S=Si, Si+1, Si+2, . . . , Si+Nis different after each authentication, even if an identical succession of blocks of user data Biis to be sent. This means that the sequence S of the signatures Siis a function of kIDand r, that is to say S=S(kID, r), for example. For a hacker, the sequence S appears to be a random succession of bits.

Thus, heavy cryptographic primitives are used to iteratively produce and transmit via a data channel a sequence or succession S of signatures Si, or, when the SENT protocol is used, for example, a succession of bits, on the basis of a secret key k, a random number r and a succession of blocks of user data Bi. In this case, the calculation function is chosen such that a hacker cannot calculate the next signature Si+1in advance with a feasible level of involvement from knowledge of the random number R, all previous blocks of user data Biand all previous signatures Si.

The encryption devices104and122of the data transmitter100and of the data receiver120may also have a block filler200which is operable to fill the block of user data Bithat is to be encrypted prior to the encryption in order to obtain filled blocks of user data. The encryption device104or122, e.g. an AES encryption device, is operable to obtain the encryption result VEiusing the filled blocks of user data, and the extractor is operable to extract a portion of the encryption result VEi, which portion is smaller than the block of user data Bi. Using the SENT protocol, the extracted portion comprises 1 bit, for example. This one bit is used in the SENT protocol as a signature Sior as an integrity protection bit. In this case, it is possible to use AES encryption and the key k=kID, for example, for the encryption.

The message formatter110then appends the ascertained signatures Sito the unencrypted block of user data Biin order to obtain a transmission packet BiSi. This transmission packet BiSican be transmitted to the data receiver120, for example. In this case, the data receiver120performs exactly the same steps as the data transmitter100using the same initial values, e.g. using the secret key kIDand the encrypted version r of the random number R. The encryption device126of the data receiver120is thus operable to encrypt the received block of user data Bi′ in order to obtain an encryption result VEi*. Next, the same portion is extracted from this encryption result VEi* as in the case of the data transmitter100in order to obtain a reference signature Si* in order to compare the reference signature Si* with the received signature Si′.

FIG. 7ashows transmission of a transmission packet BiSifrom a data transmitter100via a communication channel204to a data receiver120, wherein the data receiver120receives the transmission packet Bi′Si′. In the event of undisturbed or correct transmission of the transmission packet BiSi, the data receiver120receives a transmission packet (Bi′Si′)=(BiSi), and the received signature Si′ is the same as the reference signature Si* and therefore also the same as the transmitted signature Si.

FIG. 7bshows transmission of a transmission packet BiSifrom a data transmitter100via a communication channel204to a data receiver120, wherein a hacker206manipulates the transmission packet BiSiduring the transmission. When a hacker206has modified the transmitted blocks of user data Bi′, the data receiver120receives a transmission packet (Bi′Si′)=(BiSi) ⊕ Δiinstead of (Bi′Si′)=(BiSi), where Δidenotes the modification by the hacker206. Using the SENT protocol, all subsequent signature pairs (Si+1′, Si+1*), (Si+2′, Si+2*), . . . , (Si+N′, Si+N*) will therefore differ with the probability of p=½ as a result of the avalanche effect (error propagation effect) of the block encryption chain of the encryption device, which may have a CBC-MAC design, for example. This means that following malicious modification and when the data receiver120has received120N transmission packets Bi′Si′, the probability of this attack remaining unnoticed is P=2−N. After the transmission of N=20 transmission packets Bi′Si′, for example, the probability of the attack remaining unnoticed is therefore 1:1,000,000.

The effect achieved by the data transmitter100and the data receiver120is therefore that the transmitted volume of information which is required for protecting the data is minimal and constant. This firstly ensures the realtime capability of the protocol used. Secondly, as the number N of transmitted signatures Siincreases, the certainty of recognition of an attack increases exponentially. Secure error recognition is thus possible; it merely occurs after a delay. Many existing protocol standards, e.g. SENT, SENT/SPC, SEC, PSI5, CAN and FlexRay, can therefore be extended by data integrity protection without losing backward compatibility.

When the transmission packets BiSiare being transmitted from the data transmitter100to the data receiver120, a transmission error may occur which, for example for technical reasons, could be caused by severe electromagnetic noise. When a transmission error occurs in a transmitted block of user data Bi′, the error propagation property of the encryption device, which has a CBC-MAC design, for example, would result in all subsequent transmitted blocks of user data Bi′ not matching with a given probability. When the SENT protocol is used, for example, with a signature Siwhich has a length of 1 bit, for example, this probability is p=½, just as in the case of modification by a hacker206. For this reason, the data transmitter100and the data receiver120may have a resynchronization device which is operable to take at least one resynchronization event as a basis for actuating the encryption device104or126such that the first encryption result VE1is not dependent on a chronologically prior encryption result VE1−iand that an input for encrypting the first block of user data B1is dependent only on predetermined data and that the at least second encryption result VE2is dependent on the first encryption result VE1, wherein the predetermined data comprise the initial vector IV stored in a memory, a random number freshly obtained from the challenge/response device112or136or an encrypted version of the random number or a block of user data Bi. Furthermore, the resynchronization device138of the data receivers120may be operable, by way of example, to trigger a resynchronization event such that the event can be detected by a data transmitter100.

An attack and a technical transmission error can be distinguished as follows. When a transmission packet Bi′Si′ is received which has an invalid signature Si′, the received transmission packet Bi′Si′ is rejected and used for no further calculations. In addition, data receiver120may have an error counter140which is operable to count each transmission error or each rejected transmission packet Bi′Si′ in order to obtain an error rate. The error counter140is operable to ascertain the error rate using only a prescribed number of recently received and successive transmission packets (Bi′Si′). Next, the data receiver120triggers a resynchronization event which resets its own encryption device126and the encryption device104of the data transmitter100, with the internal variables of the encryption chain (e.g. the output of the AES encryption and, by way of example, the input of the XOR addition) being reset to the initial vector IV, for example. Next, the transmission of the transmission packets BiSiis continued for the signature Siof the resynchronized encryption device104.

The data receiver120then uses the error counter140to check that the error rate, e.g. the number of errors which have occurred, exceeds a prescribed value in relation to the number of transmitted transmission packets Bi′Si′. If the error rate is the same as or below the prescribed value, it is assumed that there is a random technical transmission error. If this prescribed value is exceeded, however, an attack is assumed. In this case, all subsequent received transmission packets Bi′Si′ can be rejected, for example, and it is also possible for further measurements to be carried out, for example.

In order to protect the transmission of the transmission packet BiSibetween the data transmitter100and the data receiver120against side channel attacks, such as against DPA (DPA=differential power analysis) and DFA (DFA=differential fault analysis), the first step180can be extended for setting up the connection, that is to say the authentication.

FIG. 8shows a three-way challenge/response check for the reciprocal authentication between the data transmitter100and the data receiver120. The three-way challenge/response check involves another piece of information being transmitted, with the challenge/response device112and136of the data transmitter100and of the data receiver120each having a random number generator or a cryptographic or pseudo random number generator which are operable to generate a true or pseudo random random number.

First, the data transmitter100generates two random numbers, a challenge random number RPand an additional random number rP, which has a length of 48 bits, for example. In the same way, the data receiver120generates two random numbers, a challenge random number RTand a random number rT, which, by way of example, has the same length as the random number rP, for example 48 bits in this case. The challenge random numbers RPand RTmay each have a prescribed length of 72 bits, for example. The shared secret key kIDand the two public random numbers rPand rTcan then be used to calculate a session key k0using a session key derivation function SK:
k0=SK(kID, rP, rT).
In this regard,FIG. 8shows a first message210being transmitted from the data transmitter100to the data receiver120by way of example. The first message210has the challenge random number RPand the public random number rP. Next, the data receiver120ascertains the session key k0and an encrypted version cP=AES (key=k0, RP) of the challenge random number RPfrom the data transmitter100using the session key k0.

In a second message212, the data receiver120transmits to the data transmitter100the encrypted version cPof the random number RPfrom the data transmitter100, the challenge random number RTand the public random number rT. Next, the data transmitter100first of all ascertains the session key k0and, using the session key k0, ascertains its own encrypted version cP′=AES (key=k0, RP) of its own challenge random number RP. If its own encrypted version cP′ of its own challenge random number RPmatches the encrypted version cP—obtained from the data receiver120—of its own challenge random number RP(cP′=cP), the data receiver120has authenticated itself to the data transmitter100, whereupon the data transmitter100accepts the data receiver120. If the authentication is successful, the data transmitter100also ascertains the encrypted version cT=AES (key=k0, RT) of the challenge random number RTfrom the data receiver120with the session key k0.

In a third message214, the encrypted version cTof the challenge random number RTfrom the data receiver120is transmitted. The data receiver120ascertains its own encrypted version cT′=AES (key=k0, RT) of its own challenge random number RTand then checks whether the encrypted Version cT—obtained with the third message214—of its own random number RTmatches its own encrypted version cT′ of the random number RT. If its own encrypted version cT′ of its own challenge random number RTmatches the obtained encrypted version cTof the random number RT(cT=cT′), the data transmitter100has authenticated itself to the data receiver, whereupon the data receiver120accepts the data transmitter100. Otherwise (cT≠cT′), and the connection setup is terminated.

Alternatively, the validity of the authentication can be checked by virtue of the data transmitter100changing directly to the data transmission phase instead of transmitting an encrypted version cTof its own random number RTto the data receiver120in a third message214. In this case, the authentication can take place directly by means of the signature Si, for example.

In the embodiment shown inFIG. 5, the session key derivation function SK has an AES encryption and a finite field operation called nonleaking map (NLM). The session key obtained in this manner is then used for the second step182fromFIG. 4, that is to say for the transmission of the transmission packets BiSi.

FIG. 9shows a further aspect of an encryption device104and126for obtaining a secure but efficient signature which is also protected against side channel attacks. In this case, the design of the MAC chain is based on an HMAC (HMAC=Keyed-Hash Message Authentication Code), a type of MAC which is calculated on the basis of a cryptographic hash function, with a Matyas-Meyer-Oseas design being used as an elementary building block. Prior to the encryption, the blocks of user data Biare filled by a block filler200in order to obtain filled blocks of user data. These filled blocks of user data are then encrypted, with AES encryption being able to be used, for example.FIG. 9reveals that new keys k1, k2, k3, . . . , kNare used for every encryption of the MAC calculation chain. These keys are generated iteratively from the previous ones. By way of example, a block of user data Biis encrypted with the key kiin order to obtain an encryption result VEi. The subsequent key which is used for encrypting the subsequent block of user data can be obtained from a combination of the encryption result VEiand the block of user data Bt, for example. This combination can be made using XOR addition or XNOR addition, for example. The first key k1of the calculation chain is derived from the session key k0and the challenge random numbers RPand RT. The use of the variable key kiinstead of the shared secret key kIDfor the encryption is a prerequisite so that the transmission of the transmission packets BiSibetween data transmitter100and data receiver120is protected against side channel attacks. In the embodiment shown inFIG. 9, the extracted portion of the encryption result VEi, which portion is used as a signature Si, is smaller than the corresponding block of user data Bi. The data transmitter100and the data receiver120therefore introduce a previously unknown level of security against attacks, for example against protocol attacks and against physical attacks and also particularly against differential side channel attacks, in the field of automotive sensor systems, for example.

In addition, when realtime requirements are high or extreme, it may be necessary for a data receiver120already to require data from a data transmitter100, for example, before authentication between the data transmitter100and the data receiver120can be performed successfully. In this case, the data transmitter100and the data receiver120may be operable, by way of example, to transmit transmission packets BiSiat the beginning of the data transmission which are (initially) not authenticated or unable to be authenticated. The authentication can then be added after a delay, for example.

The signatures Sitransmitted with the transmission packets BiSimay initially be dummy signatures, for example, which cannot be evaluated or used for authentication. There may therefore be two states, a first state in which unauthenticated transmission packets BiSiare transmitted and a second state in which authenticated transmission packets BiSiare transmitted. A change from the first state to the second state can be ensured, by way of example, by virtue of the data receiver120being operable to receive only a limited number of transmission packets BiSi. This number can be stipulated or prescribed in advance, for example, during the first state. The data receiver120may also be operable to transmit the random number R, as shown inFIG. 5, to the data transmitter100during the first state. The data transmitter100may also be operable to transmit transmission packets BiSiduring the first state which have a data pattern which is known, for example, as signature Si. In this case, the data receiver120is able, by way of example, to interpret a change in the known data pattern by the data transmitter100as a change from the first state to the second state, with the transmission packets BiSisubsequently being able to be transmitted in authenticated fashion in the second state.

If a change from the first state to the second state does not take place within a prescribed time window or time interval or after a prescribed number of transmitted transmission packets BiSi, for example, the data receiver120may be operable, by way of example, to interpret this as an attack and to terminate the transmission, for example. Alternatively, the data transmitter100and the data receiver120may be operable, by way of example, to count the number of transmission packets BiSi, with a change from the first state to the second state being able to take place after a (firmly) prescribed number of transmission packets BiSi. Optionally, the change from the first state to the second state can take place after a prescribed time, e.g. a waiting time.

In addition, it is possible to check the validity of the authentication by changing directly to the data transmission phase instead of checking the validity of the authentication by sending back r′ (encrypted version of the random number R), cP(encrypted version of the random number RP) or cT(encrypted version cPof the random number RT). The authentication is then provided directly by the signature Si, for example.

The embodiments of protecting the integrity of the data transmitter100and the data receiver120can be implemented in further protocols, e.g. in further inexpensive bidirectional protocols, such as in the PSI5 protocol. The embodiments described herein are always advantageous when it is not necessary to recognize errors immediately after every transmission of a transmission packet BiSi, that is to say when recognition in realtime is not necessary. Furthermore, the listed embodiments are always advantageous when it is not possible—as a result of the available bandwidth and/or the maximum delay time to be observed—to insert an entire MAC after each block of user data Bior after a plurality of blocks of user data. The embodiments shown can therefore be used for extending existing protocols, since the transmission requires only very few bits and even, depending on the embodiment, only a single bit, with the security increasing with every transmitted block of user data Bi, since from the second block of user data B2onward, the respective previous encryption result VEiis used for calculating the signature Si.

Terms such as “first”, “second”, and the like, are used to describe various elements, regions, sections, etc. and are not intended to be limiting. Like terms refer to like elements throughout the description.