Method for increasing the security of a communication between an infrastructure and a motor vehicle

Abstract

The invention relates to a method for increasing the security of a communication between an infrastructure-side system, in particular an AVP system, of an infrastructure, in particular a parking lot, and a motor-vehicle-side system, in particular an AVP system, of a motor vehicle. Both systems agree on a shared secret which is subsequently used for securing a communication between the two systems. The invention also relates to a system for an infrastructure, to a further method for increasing the security of a communication between an infrastructure-side system of an infrastructure and a motor-vehicle-side system of a motor vehicle, to a system for a motor vehicle, to a motor vehicle, to a computer program and to a machine-readable storage medium.

Description

[0001] Description

[0002] title

[0003] Method for increasing the security of communication between infrastructure and motor vehicle

[0004] The invention relates to two methods for increasing the security of communication between an infrastructure-side system of an infrastructure and a motor vehicle-side system of a motor vehicle, a system for an infrastructure, a system for a motor vehicle, a motor vehicle, a computer program and a machine-readable storage medium.

[0005] State of the art

[0006] In automated valet parking (AVP), vehicles are driven driverlessly within a parking space. An infrastructure installed in the parking space monitors the vehicle's surroundings to guide the vehicle within the parking space without collisions and at a sufficient distance from other road users. This requires communication between the infrastructure and the vehicle to be as secure as possible.

[0007] The published patent application DE 10 2016213145 A1 discloses a method for authenticating a motor vehicle.

[0008] The published patent application DE 10 2012 222 562 A1 discloses a system for managed parking areas for transferring a vehicle from a starting position to a destination position.

[0009] Disclosure of the invention The object underlying the invention is to provide a concept for increasing the security of communication between an infrastructure-side system of an infrastructure and a motor vehicle-side system of a motor vehicle.

[0010] This object is achieved by means of the respective subject matter of the independent claims. Advantageous embodiments of the invention are the subject matter of the respective dependent subclaims.

[0011] According to a first aspect, a method for increasing the security of communication between an infrastructure-side system, in particular an AVP system, of an infrastructure, in particular a parking lot, and a motor vehicle-side system, in particular an AVP system, of a motor vehicle, in particular an AVP motor vehicle, is provided, comprising the following steps:

[0012] Agreeing on a shared secret by the infrastructure-side system with the vehicle-side system, wherein, in the case that the infrastructure-side system is the sender of payload data for the vehicle-side system as the recipient of the payload data, the method comprises the following steps:

[0013] Calculating a checksum over the payload and the shared secret by the infrastructure-side system, and

[0014] Sending the payload and the checksum to the vehicle-side system by the infrastructure-side system, wherein, in the case that the infrastructure-side system is the recipient of payload for the infrastructure-side system from the vehicle-side system as the sender of the payload, the method comprises the following steps:

[0015] Receiving the payload data and a checksum from the vehicle-side system by the infrastructure-side system,

[0016] Calculating a checksum over the payload and the shared secret by the infrastructure-side system to determine another checksum,

[0017] Determining, based on the checksum and the further checksum, whether the payload data may be used on the infrastructure side or not. According to a second aspect, a system, in particular an AVP system, is provided for an infrastructure, in particular a parking lot, which is configured to carry out all steps of the method according to the first aspect.

[0018] According to a third aspect, a method for increasing the security of communication between an infrastructure-side system, in particular an AVP system, of an infrastructure, in particular a parking lot, and a motor vehicle-side system, in particular an AVP system, of a motor vehicle, in particular an AVP motor vehicle, is provided, comprising the following steps:

[0019] Agreeing on a shared secret by the vehicle-side system with the infrastructure-side system, wherein, in the case that the vehicle-side system is the sender of payload data for the infrastructure-side system as the recipient of the payload data, the method comprises the following steps:

[0020] Calculating a checksum of the payload and the shared secret by the vehicle-side system, and

[0021] Sending the payload and the checksum to the infrastructure-side system by the motor vehicle-side system, wherein, in the case that the motor vehicle-side system is the recipient of payload for the motor vehicle-side system from the infrastructure-side system as the sender of the payload, the method comprises the following steps: receiving the payload and a checksum from the infrastructure-side system by the motor vehicle-side system, calculating a checksum over the payload and the shared secret by the motor vehicle-side system to determine a further checksum, determining, based on the checksum and the further checksum, by the motor vehicle-side system whether the payload may or may not be used on the motor vehicle side. According to a fourth aspect, a system, in particular an AVP system, is provided for a motor vehicle, wherein the system is configured to carry out all steps of the method according to the third aspect.

[0022] According to a fifth aspect, a motor vehicle, in particular an AVP motor vehicle, is provided which comprises the system according to the fourth aspect.

[0023] According to a sixth aspect, a computer program is provided which comprises instructions which, when the computer program is executed by a computer, for example by the system according to the second and / or the fourth aspect, cause the computer to carry out a method according to the first aspect and / or according to the third aspect.

[0024] According to a seventh aspect, a machine-readable storage medium is provided on which the computer program according to the sixth aspect is stored.

[0025] The invention is based on and includes the finding that a common secret, for example a common cryptographic key using a key exchange method, is agreed between the motor vehicle-side system and the infrastructure-side system.

[0026] Furthermore, according to the concept described here, for payload data determined by one of the two systems, i.e., the infrastructure-side system and the vehicle-side system, for the other of the two systems, a checksum is calculated by the system determining the payload data using the shared secret. Thus, a checksum is calculated for the payload data and the shared secret.

[0027] For example, the secret is appended to the payload, and then the checksum is calculated over the entire data set. Example: 100-bit payload, 32-bit secret -> Calculate the checksum over the entire 132 bits. The secret can be placed before or after the payload in the data set, for example.

[0028] For example, calculating the checksum involves hashing the payload based on the shared secret or using the shared secret. For example, the shared secret and the payload form a joint data set, which is hashed. Specifically, a hash value is calculated for the payload and the shared secret.

[0029] As a result of hashing, a hash value is available, which is sent in addition to the payload data.

[0030] In general, as a result of calculating the checksum, a checksum is available, which is sent in addition to the payload data.

[0031] On the receiving side, payload data and a checksum are received from the corresponding system. This payload data is verified using the received checksum as follows: The system calculates another checksum for the payload data together with the secret in the same way as the sending system. This means, in particular, that there is an identical predetermined checksum calculation rule, by which the corresponding checksum is calculated on the vehicle side (i.e., by the vehicle-side system) and on the infrastructure side (i.e., by the infrastructure-side system).

[0032] If, for example, the payload data has not been changed, the system receiving the payload data will calculate a further checksum as a result of calculating the further checksum, which is equal to the received checksum. If there is a difference between the checksum calculated by the system sending the payload data and the checksum calculated by the system receiving the payload data, i.e. the further checksum, the system receiving the payload data can assume, for example, that the payload data has been falsified or that the payload data, if the recipient is the vehicle-side system, is intended for a different vehicle. This is because, in the latter case, the infrastructure-side system used a different secret to calculate the checksum than the secret that the vehicle-side system agreed upon with the infrastructure-side system.

[0033] Thus, for example, multiple motor vehicles can receive payload data for a specific vehicle. However, only that specific vehicle will calculate the same checksum, which is equal to the received checksum—i.e., the checksum associated with the payload or sent with it. This is because the secret used to calculate this checksum is known only to the infrastructure-side system and the vehicle-side system of that specific vehicle.

[0034] As a result, the security of communication between the infrastructure and the motor vehicle can be advantageously and efficiently increased. In particular, communication of user data between the motor vehicle and the infrastructure can advantageously be carried out unencrypted, for example, which saves the computing resources required for encryption and decryption.

[0035] Furthermore, it can thus be advantageously determined on the motor vehicle side whether the received user data is intended for the motor vehicle or not.

[0036] If yes, this payload data can be used by the vehicle. If no, it is not used by the vehicle. A driving command not intended for the vehicle will therefore not be executed by the vehicle, which can effectively increase safety.

[0037] This provides the technical advantage that, for example, communication between the AVP vehicle and the infrastructure can be efficiently increased within the framework of an AVP process. Furthermore, it can be advantageously and efficiently ensured that payload data for a specific vehicle is used only by that vehicle and not by another vehicle. For example, it is determined that the payload data was transmitted uncorrupted through a communication channel between the two systems if the checksum is equal to the further checksum. In this case, it is determined, for example, that the payload data may be used on the receiver side.

[0038] For example, if the checksum is not equal to the other checksum, it is determined that the payload was corrupted and transmitted through a communication channel between the two systems. In this case, it is determined, for example, that the payload may not be used on the receiving side.

[0039] For example, the system receiving the payload data compares the checksum and the additional checksum, and based on the comparison, the system receiving the payload data determines whether the payload data may be used or not. For example, the system receiving the payload data determines that the payload data may be used if the checksum is equal to the additional checksum. For example, the system receiving the payload data determines that the payload data may not be used if the checksum is unequal to the additional checksum.

[0040] For example, the system receiving the payload determines that the payload will not be discarded if the checksum is equal to the further checksum. For example, the system receiving the payload determines that the payload will be discarded if the checksum is not equal to the further checksum, so that, for example, the payload is discarded by the system receiving the payload.

[0041] Furthermore, the concept ensures that components involved in communication between the infrastructure and the vehicle cannot corrupt the transmitted payload data due to a programming error. If the payload data were only protected by a checksum, any component could modify the payload data and generate a new checksum. This could also happen, in particular, if a component fails to behave according to its intended purpose due to an error. For this to happen, the component only needs to know the checksum calculation method—which cannot be ruled out.

[0042] By including the shared secret in the checksum, it is ensured that no components involved in the communication can issue a correct checksum because they certainly do not know the secret.

[0043] In one embodiment of the method according to the first aspect, it is provided that the agreement of the shared secret comprises an encrypted transmission of the shared secret by the infrastructure-side system to the motor vehicle-side system or an encrypted reception of the shared secret by the infrastructure-side system from the motor vehicle-side system.

[0044] This provides, for example, the technical advantage of efficiently coordinating the secret. Encryption, in particular, provides the technical advantage of making it difficult or impossible for third parties and / or components involved in the communication to discover the shared secret.

[0045] In one embodiment of the method according to the first aspect, it is provided that the infrastructure-side system determines a random number as the shared secret, which is sent in encrypted form by the infrastructure-side system to the motor vehicle-side system.

[0046] This provides, for example, the technical advantage that the shared secret can be efficiently determined and agreed upon.

[0047] In one embodiment of the method according to the first aspect, it is provided that the shared secret is agreed upon using a key exchange method, so that the shared secret is a shared cryptographic key. The use of a key exchange method, for example, provides the technical advantage that, even if communication between the vehicle-side system and the infrastructure-side system is intercepted by third parties, the intercepted communication cannot reveal the shared cryptographic key. Thus, the shared secret can be agreed upon efficiently even over a communication channel that is not secure against eavesdropping, i.e., for example, is not encrypted.Thus, for example, communication between a vehicle-side system and an infrastructure-side system can be unencrypted communication, so that on both sides the computational effort required for encryption can be saved due to the non-encryption.

[0048] In one embodiment of the method according to the first aspect, it is provided that the shared secret, in particular the shared cryptographic key or the random number, is agreed upon using a broadcast communication method, in particular a V2X protocol.

[0049] This provides, for example, the technical advantage of efficiently agreeing on the shared secret. In particular, the use of a V2X protocol offers the technical advantage of using a standardized protocol for communication between the infrastructure-side system and the vehicle-side system.

[0050] In one embodiment of the method according to the first aspect, it is provided that the common cryptographic key is agreed upon by means of a Diffie-Hellman (DH) method or an Elliptic Curve Diffie-Hellman (ECDH) method.

[0051] This provides, for example, the technical advantage of using a particularly suitable key exchange method. In one embodiment of the method according to the first aspect, the payload data includes one or more of the following payload data: driver's license, current time, time synchronization request, time synchronization response, confirmation of vehicle characteristics, in particular dimensions, interface version, etc.

[0052] This provides the technical advantage, for example, that particularly useful user data can be secured.

[0053] An interface version is a version of an interface. Such an interface is an interface between a motor vehicle and the infrastructure, i.e. between the motor vehicle system and the infrastructure system. On this interface, depending on the version of the interface, the driving permit, for example, is described differently or its meaning changes. This allows the interface to be further developed. In version 1.0 of the interface, for example, the driving permit contains information for both directions of travel. In version 2.0, however, this only contains information for the required direction of travel (e.g. to save data). The infrastructure knows in which direction the motor vehicle should move.

[0054] It is now important that the motor vehicle and infrastructure agree on a version of the interface at the outset so that the data can be interpreted correctly.

[0055] In one embodiment of the method according to the first aspect, it is provided that calculating the checksum comprises calculating a cyclic redundancy check (CRC checksum) or a cryptographic hash value.

[0056] This provides the technical advantage, for example, that the checksum calculation can be carried out particularly efficiently. In particular, it provides the technical advantage that hardly any computing power is required, since checksums, especially CRC checksums, can be calculated very easily. CRC stands for "Cycle Redundancy Check."

[0057] In one embodiment of the method according to the third aspect, it is provided that the agreement of the shared secret comprises an encrypted transmission of the shared secret by the motor vehicle-side system to the infrastructure-side system or an encrypted reception of the shared secret by the motor vehicle-side system from the infrastructure-side system.

[0058] This provides, for example, the technical advantage of efficiently coordinating the secret. Encryption, in particular, provides the technical advantage of making it difficult or impossible for third parties and / or components involved in the communication to eavesdrop on the shared secret.

[0059] In one embodiment of the method according to the third aspect, it is provided that the motor vehicle-side system determines a random number as the shared secret, which is sent in encrypted form by the motor vehicle-side system to the infrastructure-side system.

[0060] This provides, for example, the technical advantage that the shared secret can be efficiently determined and agreed upon.

[0061] In one embodiment of the method according to the third aspect, it is provided that the shared secret is agreed upon by means of a key exchange method, so that the shared secret is a shared cryptographic key.

[0062] In one embodiment of the method according to the third aspect, it is provided that the shared secret, in particular the shared cryptographic key or the random number, is agreed upon using a broadcast communication method, in particular a V2X protocol. In one embodiment of the method according to the third aspect, it is provided that the shared cryptographic key is agreed upon using a Diffie-Hellman (DH) method or an Elliptic Curve Diffie-Hellman (ECDH) method.

[0063] In one embodiment of the method according to the third aspect, it is provided that the payload data comprise one or more of the following payload data: driver's license, current time, request for time synchronization, response for time synchronization, confirmation of motor vehicle properties, in particular dimensions, interface version, etc.

[0064] In one embodiment of the method according to the third aspect, it is provided that calculating the checksum comprises calculating a cyclic redundancy check (CRC checksum) or a cryptographic hash value.

[0065] Statements made in connection with the method according to the first aspect apply analogously to the method according to the third aspect, and vice versa. Technical functionalities of the method according to the first aspect result analogously from corresponding technical functionalities of the method according to the third aspect, and vice versa. This means that features of the method according to the first aspect result analogously from corresponding features of the method according to the third aspect, and vice versa.

[0066] The system according to the second aspect is, for example, programmatically configured to execute a computer program comprising instructions which, when the computer program is executed by a computer, cause the computer to execute a method according to the first aspect.

[0067] For example, the system according to the fourth aspect is configured to execute a computer program comprising instructions that, when executed by a computer, cause the computer to execute a method according to the third aspect. The method according to the first aspect is, for example, a computer-implemented method.

[0068] The method according to the third aspect is, for example, a computer-implemented method.

[0069] Statements made in connection with the method according to the first aspect apply analogously to the system according to the second aspect, and vice versa. This means that technical functionalities and technical features of the system according to the second aspect result analogously from corresponding technical functionalities and technical features of the method according to the first aspect, and vice versa.

[0070] Statements made in connection with the method according to the third aspect apply analogously to the system according to the fourth aspect, and vice versa. This means that technical functionalities and technical features of the system according to the fourth aspect result analogously from corresponding technical functionalities and technical features of the method according to the third aspect, and vice versa.

[0071] A system within the meaning of the description is, for example, an AVP system, i.e. in particular a motor vehicle-side AVP system or an infrastructure-side AVP system.

[0072] A motor vehicle within the meaning of the description is, for example, an AVP motor vehicle.

[0073] A motor vehicle as defined in the description is located within the infrastructure.

[0074] An infrastructure within the meaning of the description includes, for example, or is, for example, a parking lot, train station, loading station, port, loading port, car terminal, ferry dock, factory, motor vehicle factory, or motor vehicle plant. A motor vehicle within the meaning of the description is, for example, a motor vehicle that is at least highly automated. This means that the motor vehicle is, in particular, configured to operate in at least a highly automated manner.

[0075] The system for a motor vehicle, for example, is designed to drive a motor vehicle at least in a highly automated manner.

[0076] The abbreviation "AVP" stands for "Automated Valet Parking" and can be translated into German as "automatic parking service". An AVP process includes, for example, at least highly automated driving of the AVP vehicle from a drop zone, also called a drop-off location, to a parking location and, for example, at least highly automated driving of the AVP vehicle from a parking location to a pick-up location, also called a pickup zone. At the drop-off location, i.e. the drop zone, a driver of the AVP vehicle drops off the AVP vehicle for an AVP process. At a pick-up location, i.e. the pickup zone, the AVP vehicle is picked up after the end of the AVP process. An AVP process therefore starts in particular at the drop zone. An AVP process therefore ends in particular at the pickup zone. The pickup zone can be the same as or different from the drop zone.

[0077] An AVP motor vehicle is a motor vehicle that can participate in an AVP process.

[0078] The AVP process is performed on the infrastructure side using or by an exemplary AVP system according to the second aspect and is performed on the AVP motor vehicle side using or by an exemplary AVP system according to the fourth aspect.

[0079] An AVP process can be an AVP process according to one of the following AVP types: AVP type 1, AVP type 2, and AVP type 3. Within an AVP process, however, the AVP types can also change. This means, for example, that part of an AVP process is carried out according to AVP type 1, and another part of the AVP process is carried out according to AVP type 2 or AVP type 3. This means, for example, that an AVP process can be divided into sub-AVP processes, each of which is carried out according to one of the AVP types 1, 2, and 3.

[0080] AVP Type 1 designates a vehicle-centric AVP process. Primary responsibility for the AVP process lies with the AVP vehicle, i.e., the vehicle-based AVP system.

[0081] AVP Type 2 characterizes an infrastructure-centric AVP process. The primary responsibility for the AVP process lies with the infrastructure, i.e., the infrastructure-side AVP system.

[0082] AVP Type 3 denotes a vehicle-infrastructure-shared AVP process. Here, primary responsibility for the AVP process is shared between the AVP vehicle, i.e., the vehicle-side AVP system, and the infrastructure-side AVP system.

[0083] An AVP process includes the following operations or functions:

[0084] 1. Determine a target position, which lies within the parking space, for the AVP vehicle.

[0085] 2. Planning a route from a starting position, which is enclosed by the parking lot, to the destination position.

[0086] 3. Detecting an object and / or an event and reacting accordingly to a detected object and / or a detected event.

[0087] 4. Locate the AVP vehicle within the parking lot.

[0088] 5. Calculate a target trajectory for the AVP vehicle based on the planned route.

[0089] 6. Controlling the lateral and longitudinal guidance of the AVP vehicle based on the calculated target trajectory. The following table indicates which of these processes or functions are performed by the AVP vehicle, i.e., the vehicle-side AVP system, or the infrastructure-side AVP system, depending on the AVP type. "I" stands for "infrastructure," i.e., the infrastructure-side AVP system, and "K" for "AVP vehicle." "I" indicates that the process is performed by the AVP system, and "K" indicates that the process is performed by the vehicle-side AVP system:

[0090] The table above indicates, for each function specifically for each AVP type, whether the function is performed by the infrastructure, i.e., the infrastructure-side AVP system, or by the AVP vehicle, i.e., the vehicle-side AVP system. In some cases, the function may be performed by both the infrastructure-side AVP system and the AVP vehicle.

[0091] With regard to object and event detection for AVP type 1, it can optionally be provided that in addition to the vehicle-side AVP system, the infrastructure-side AVP system also performs this function.

[0092] The AVP types 1, 2 and 3 described here are further described in detail in ISO standard 23374-1:2021(E).

[0093] The AVP motor vehicle is at least a highly automated motor vehicle. Such a motor vehicle is equipped for at least highly automated driving. Highly automated driving corresponds to automation level 4 according to the definition of the Federal Highway Research Institute (BASt).

[0094] The fact that a motor vehicle, in particular an AVP motor vehicle, is equipped for at least highly automated driving includes both the case where the motor vehicle is equipped for highly automated driving and the case where it is equipped for fully automated driving. Fully automated driving corresponds to automation level 5 according to the BASt definition.

[0095] Highly automated guidance means that for a certain period of time in a specific situation (e.g. driving on a motorway, driving in a parking lot, overtaking an object, driving in a lane defined by lane markings), the longitudinal and lateral guidance of the motor vehicle are automatically controlled. The driver of the motor vehicle does not have to manually control the longitudinal and lateral guidance of the vehicle. The driver does not have to constantly monitor the automatic control of the longitudinal and lateral guidance in order to be able to intervene manually if necessary. If necessary, a takeover request is automatically issued to the driver to take over control of the longitudinal and lateral guidance, in particular with a sufficient time reserve. The driver must therefore potentially be able to take over control of the longitudinal and lateral guidance.Limits of the automatic control of lateral and longitudinal guidance are automatically detected. With highly automated guidance, it is not possible to automatically achieve a minimal-risk state in every initial situation.

[0096] Fully automated guidance means that in a specific situation (e.g. driving on a motorway, driving within a parking lot, overtaking an object, driving within a lane defined by lane markings), the longitudinal and lateral guidance of the vehicle are automatically controlled. The driver of the vehicle does not have to manually control the longitudinal and lateral guidance of the vehicle. The driver does not have to monitor the automatic control of the longitudinal and lateral guidance in order to intervene manually if necessary. Before the automatic control of the lateral and longitudinal guidance is terminated, the driver is automatically prompted to take over the driving task (controlling the lateral and longitudinal guidance of the vehicle), particularly with a sufficient time reserve. If the driver does not take over the driving task, the vehicle is automatically returned to a state with minimal risk.Limits of the automatic control of lateral and longitudinal guidance are automatically detected. In all situations, it is possible to automatically return to a system state with minimal risk.

[0097] The motor vehicle comprises, for example, one or more environmental sensors. Such environmental sensors can also be called motor vehicle environmental sensors. Such environmental sensors are, for example, included in the motor vehicle system. A motor vehicle environmental sensor system comprises, for example, one or more such environmental sensors. The system according to the second aspect comprises, for example, one or more environmental sensors that are spatially distributed within the infrastructure, in particular within the parking space. Such environmental sensors can be referred to, for example, as infrastructure environmental sensors. An infrastructure environmental sensor system comprises, for example, one or more such infrastructure environmental sensors.

[0098] An environmental sensor, i.e. a motor vehicle environmental sensor or an infrastructure environmental sensor, is, for example, one of the following environmental sensors: radar sensor, lidar sensor, image sensor, in particular image sensor of a video camera, for example image sensors of a stereo video camera, ultrasonic sensor, magnetic field sensor, infrared sensor.

[0099] The embodiments and exemplary embodiments described here can be combined with one another in any way, even if this is not explicitly described.

[0100] The system according to the second aspect can be called an infrastructure-side system if it is implemented in an infrastructure, in particular a parking lot.

[0101] The system according to the fourth aspect may be referred to as a motor vehicle system when implemented in a motor vehicle.

[0102] The Diffie-Hellmann algorithm requires two parameters in particular that can be specified in advance and may be publicly known. These can, for example, be agreed upon in advance or described in a standard.

[0103] The parameters are: a large, suitable prime number p and a so-called generator g. For the Diffie-Hellmann algorithm with 32-bit numbers, suitable parameters are, for example: p = 4294967087 = 2 A 32 - 209 = 0xffffff2f and g=5 or g=10. For the Diffie-Hellmann algorithm with 64-bit numbers, suitable parameters are, for example: p = 18446744073709550147 = 2 A 64 - 1469 = 0xfffffffffffffa43 and g=2 or g=5.

[0104] A stands for the exponentiation, i.e. 2 to the power of 32 or 2 to the power of 64.

[0105] The specified parameters are the largest suitable prime number that can be represented with the specified number of bits, and two possible suitable generators. A prime number p is suitable if (p-1) / 2 is also a prime number. This generally means that for an n-bit secret, for example, the parameter p is the largest prime number that can be represented with the specified number of bits, here n bits, and that satisfies this property.

[0106] The method according to the first aspect comprises, for example, determining user data for the motor vehicle-side system by the infrastructure-side system.

[0107] The method according to the third aspect comprises, for example, determining user data for the infrastructure-side system by the motor vehicle-side system.

[0108] The invention is explained in more detail below using preferred embodiments. These show:

[0109] Fig. 1 is a flowchart of a method according to the first aspect,

[0110] Fig. 2 is a flowchart of a method according to the third aspect,

[0111] Fig. 3 a system according to the fourth aspect,

[0112] Fig. 4 a system according to the second aspect,

[0113] Fig. 5 shows a machine-readable storage medium according to the seventh aspect and Fig. 6 shows a parking space.

[0114] In the following, the same reference symbols may be used for the same features.

[0115] Fig. 1 shows a flowchart of a method for increasing the security of communication between an infrastructure-side system of an infrastructure and a motor vehicle-side system of a motor vehicle, comprising the following steps:

[0116] Agreeing 101 on a shared secret by the infrastructure-side system with the vehicle-side system, wherein, in the case that the infrastructure-side system is the sender of payload data for the vehicle-side system as the recipient of the payload data, the method comprises the following steps:

[0117] Calculating 103 a checksum over the payload and the shared secret by the infrastructure-side system, and

[0118] Sending 105 the payload and the checksum to the motor vehicle-side system by the infrastructure-side system, wherein in the case that the infrastructure-side system is the recipient of payload for the infrastructure-side system from the motor vehicle-side system as the sender of the payload, the method comprises the following steps: receiving 107 the payload and a checksum from the motor vehicle-side system by the infrastructure-side system, calculating 109 a checksum over the payload and the shared secret by the infrastructure-side system in order to determine a further checksum, determining 111 based on the checksum and the further checksum by the infrastructure-side system that the payload may or may not be used on the infrastructure side or that it was transmitted uncorrupted through a communication channel between the two systems.

[0119] Fig. 2 shows a flowchart of a method for increasing the security of communication between an infrastructure-side system of an infrastructure and a motor vehicle-side system of a motor vehicle, comprising the following steps: Agreeing 201 on a shared secret by the motor vehicle-side system with the infrastructure-side system, wherein in the case that the motor vehicle-side system is the sender of payload data for the infrastructure-side system as the recipient of the payload data, the method comprises the following steps: Calculating 203 a checksum over the payload data and the shared secret by the motor vehicle-side system, and Sending 205 the payload data and the checksum to the infrastructure-side system by the motor vehicle-side system, wherein in the case that the motor vehicle-side system is the recipient of payload data for the motor vehicle-side system from the infrastructure-side system as the sender of the payload data,The method comprises the following steps: receiving 207 the payload and a checksum from the infrastructure-side system by the vehicle-side system, calculating 209 a checksum over the payload and the shared secret by the vehicle-side system to determine a further checksum, determining 211 based on the checksum and the further checksum by the vehicle-side system that the payload may or may not be used on the vehicle side or that it was transmitted uncorrupted through a communication channel between the two systems.

[0120] Fig. 3 shows a system 300 according to the fourth aspect, which is comprised by or implemented in a motor vehicle 301 according to the fifth aspect. The system 300 is configured to perform all steps of the method according to the third aspect.

[0121] The vehicle-side system 300 includes a wireless communication interface 305 configured to communicate with an infrastructure-side system (not shown).

[0122] Communicating within the meaning of the description includes sending and receiving. The system 300 further comprises a processor device 307 having one or more processors (not shown). The processor device 307 is configured, for example, to perform the computational steps necessary for determining the shared secret and calculating the checksum(s) and determining the checksum.

[0123] Fig. 4 shows a system 401 according to the second aspect. The system 401 is configured to perform all steps of the method according to the first aspect.

[0124] By way of example, the system 401 comprises a video camera 403 comprising an image sensor 405. For example, the system 401 comprises a radar sensor 407.

[0125] These environmental sensors are spatially distributed within an infrastructure, in particular a parking lot (not shown), and each detects an area of ​​the infrastructure. Environmental sensor data from these environmental sensors based on the detection is output to a data processing device 409, which processes the environmental sensor data and, based on the processing, determines, for example, infrastructure assistance data for assisting an at least highly automated motor vehicle during at least highly automated driving within the infrastructure, in particular during an AVP process. Infrastructure assistance data are examples of user data.

[0126] At this point, it is noted that instead of or in addition to the environmental sensors shown in Fig. 4, more or fewer and / or other environmental sensors may be provided.

[0127] Furthermore, the infrastructure-side system 401 comprises a wireless communication interface 411 configured to communicate with one or more, in particular at least highly automated, motor vehicles located within the infrastructure, in particular within the parking lot. For example, the system 401 comprises a plurality of such wireless communication interfaces 411, which are spatially distributed within the infrastructure to achieve sufficient radio coverage.

[0128] The data processing device 409 may, for example, comprise one or more servers, one or more of which may, for example, be implemented in a cloud infrastructure.

[0129] In an embodiment not shown, system 401 is provided without infrastructure environment sensors. In this case, the infrastructure environment sensors are already part of the infrastructure.

[0130] Fig. 5 shows a machine-readable storage medium 501 according to the seventh aspect, on which a computer program 503 according to the sixth aspect is stored.

[0131] Fig. 6 shows a parking space 601 as an example of an infrastructure within which the system 401 of Fig. 4 is implemented, which here is in particular an AVP system, and within which the motor vehicle 301 of Fig.

[0132] 3, which is, for example, an AVP motor vehicle, and within which another motor vehicle 603 is located.

[0133] Motor vehicle 301 is intended to perform an AVP process, so that motor vehicle 301 can also be referred to below as an AVP motor vehicle. Within the scope of the AVP process, it is necessary that user data intended only for the AVP motor vehicle be used only by that vehicle, i.e., not by the other motor vehicle 603, for example. The concept described here advantageously enables this.

[0134] In particular, it is provided that the infrastructure-side AVP system 401 and the motor vehicle-side system 300, for example, agree on a common cryptographic key as a shared secret using a key exchange procedure. This means that the two systems 300 and 401 agree on a common cryptographic key known only to both of them using a key exchange procedure. Alternatively, the infrastructure-side AVP system 401 can send an encrypted random number as the shared secret to the motor vehicle-side system 300.

[0135] The infrastructure-side AVP system 401 determines payload data for the motor vehicle 301. This payload includes, for example, a driving command, which is to be implemented only by the motor vehicle 301 and not by the additional motor vehicle 603. The infrastructure-side AVP system 401 calculates a checksum for the payload data and the shared secret. This calculated checksum and the payload data are then sent by the infrastructure-side AVP system 401 to the motor vehicle-side AVP system 300. This system calculates a further checksum for the received payload data and the shared secret in the same way as the infrastructure-side AVP system 401. Only if the further checksum is equal to the received checksum does the motor vehicle-side AVP system 401 determine that the payload data may be used by the motor vehicle. For example, a driving command may then be implemented.

[0136] Even if the additional motor vehicle 603 can, for example, eavesdrop on communication between the infrastructure-side AVP system 401 and the motor vehicle-side system 300, it still cannot calculate the same (additional) checksum calculated by the motor vehicle-side system 300, since the additional motor vehicle 603 does not know the shared secret, the shared cryptographic key, and cannot simply calculate it from the intercepted communication. Thus, a further motor vehicle-side AVP system (not shown) of the additional motor vehicle 603 will determine that the payload data may not be used on the motor vehicle side. The driving command is therefore not implemented by the additional motor vehicle 603.

[0137] The motor vehicle-side system 300 can be the sender of user data for the infrastructure-side AVP system 401 as the recipient of this user data. Accordingly, the above statements apply analogously in connection with the infrastructure-side AVP system 401 as the sender of user data for the motor vehicle-side system 300 as the recipient of this user data.

[0138] This advantageously allows for standardization of necessary communication between the infrastructure-side AVP system and the vehicle-side system without compromising on safety aspects. For example, one or more V2X protocols can be used for communication.

[0139] When using a V2X protocol, this communication is no longer individually encrypted (1:1 communication) between the infrastructure (i.e., the infrastructure-side AVP system) and an AVP vehicle (i.e., the vehicle-side AVP system). Instead, the communication is public and can be read by any participant.

[0140] This is a sensible approach in typical V2X applications. For example, if each vehicle on a highway wants to transmit its current speed and position to all other vehicles, this can be used for many functions (e.g., automatic braking when a traffic jam is approaching, etc.).

[0141] This type of communication is called a broadcast: One participant sends its information, and all other participants read and, if necessary, use the sent data. It is therefore always a 1:n communication.

[0142] The concept described here, for example, provides for the infrastructure (i.e., the infrastructure-side system) and the motor vehicle (i.e., the motor vehicle-side system) to agree on a shared secret. This means that the infrastructure-side system and the motor vehicle-side system, for example, agree on a shared cryptographic key using a key exchange procedure. The Diffie-Hellman method can be used here, for example. The key exchange procedure can, for example, take place publicly, without eavesdroppers being able to calculate the shared secret. The shared secret, i.e., the shared cryptographic key or random number, is known only to the infrastructure and the one motor vehicle.

[0143] This ensures, for example, that, especially in the case of several motor vehicles, only one motor vehicle uses the user data intended for that one motor vehicle, for example implementing a driving command.

[0144] This makes safe AVP operation possible, for example, even if motor vehicles can overhear the communication between the infrastructure and the one AVP vehicle to be controlled.

[0145] In summary, it is specifically intended that the infrastructure and the AVP vehicle to be controlled agree on a common secret.

[0146] For example, the infrastructure initially provides the vehicle with a random number as a secret. This transmission can be encrypted so that other AVP vehicles cannot know this secret.

[0147] Alternatively, a shared secret is agreed upon using a cryptographic key exchange method, e.g. Diffie-Hellmann.

[0148] If the infrastructure now wants to send payload data to the vehicle, it calculates, for example, a CRC checksum of the payload data and the shared secret.

[0149] It then sends the payload and the calculated CRC checksum to the vehicle, but not the shared secret.

[0150] This means that someone who is listening but does not know the shared secret cannot calculate the correct CRC checksum from the payload data.

[0151] On the vehicle side, the CRC checksum is recalculated upon receipt of the payload data by adding the known secret to the received payload data and calculating the CRC checksum over the payload data with the added secret. If the calculated CRC checksum matches the received CRC checksum, this payload data is intended for the vehicle and was transmitted correctly. Otherwise, the vehicle-side system discards the payload data. This ensures, for example, that only valid driving commands are followed on the vehicle side.

[0152] Another example will further explain the concept described here.

[0153] The infrastructure-side system comprises a first server (Server 1) and a second server (Server 2). The vehicle-side system comprises a first electronic control unit (ECU) (ECU 1) and a second electronic control unit (ECU 2).

[0154] The first server determines user data for the vehicle-side system, which can be transmitted, for example, as follows.

[0155] Server 1 -- Payload --> Server 2 — Encrypted channel — > ECU1 -- Payload --> ECU2

[0156] The communication between Server 2 in the infrastructure and ECU 1 in the vehicle is encrypted and thus protected against attackers.

[0157] Within the infrastructure - inaccessible to an attacker - the payload data is generated on Server 1 and transferred unencrypted to Server 2.

[0158] In the vehicle, the payload data is decrypted by ECU 1 and then transmitted unencrypted to ECU 2.

[0159] The payload data could therefore be corrupted on the unencrypted channels or during encryption or decryption, for example, due to an error in the encryption software. This software could also mistakenly add a valid CRC to the data if it knows the algorithm. The advantage of the concept described here lies in the fact that

[0160] 1) the ECll-2 can reliably determine that it is receiving uncorrupted payload data from Server 1 - no component in the communication channel is able to calculate the correct CRC, and

[0161] 2) Hardly any computing power is required for this protection because CRCs are very easy to calculate. ECU 2 could, for example, be an ESP (braking system), which has no computing power for cryptography.

Claims

Claims 1. A method for increasing the security of communication between an infrastructure-side system (401) of an infrastructure (601) and a motor vehicle-side system (300) of a motor vehicle (301), comprising the following steps: Agreeing (101) a shared secret by the infrastructure-side system (401) with the motor vehicle-side system (300), wherein in the case that the infrastructure-side system (401) is the sender of user data for the motor vehicle-side system (300) as the recipient of the user data, the method comprises the following steps: Calculating (103) a checksum over the payload data and the shared secret by the infrastructure-side system (401), and Sending (105) the payload data and the checksum to the vehicle-side system (300) by the infrastructure-side system (401), wherein in the case that the infrastructure-side system (401) is the receiver of payload data for the infrastructure-side system (401) from the vehicle-side system (300) as the sender of the payload data, the method comprises the following steps: Receiving (107) the payload and a checksum from the vehicle-side system (300) by the infrastructure-side system (401), calculating (109) a checksum over the payload and the shared secret by the infrastructure-side system (401) to determine a further checksum, Determining (111) based on the checksum and the further checksum by the infrastructure-side system (401) whether the payload data may or may not be used on the infrastructure side.

2. The method according to claim 1, wherein the agreement of the shared secret comprises an encrypted transmission of the shared secret by the infrastructure-side system (401) to the motor vehicle-side system (300) or an encrypted reception of the shared secret by the infrastructure-side system (401) from the motor vehicle-side system (300).

3. The method according to claim 2, wherein the infrastructure-side system (401) determines a random number as the shared secret, which is sent in encrypted form by the infrastructure-side system (401) to the motor vehicle-side system (300).

4. The method according to claim 1, wherein the shared secret is agreed upon by means of a key exchange procedure, so that the shared secret is a shared cryptographic key.

5. The method according to claim 4, wherein the common cryptographic key is agreed upon using a Diffie-Hellman (DH) method or an Elliptic Curve Diffie-Hellman (ECDH) method.

6. Method according to one of the preceding claims, wherein the payload data comprises one or more of the following payload data: driving license, current time, request for time synchronization, response for time synchronization, confirmation of motor vehicle properties, in particular dimensions, interface version, etc.

7. Method according to one of the preceding claims, wherein the shared secret is agreed using a broadcast communication method, in particular a V2X protocol.

8. The method according to any one of the preceding claims, wherein calculating the checksum comprises calculating a cyclic redundancy check (CRC checksum) or a cryptographic hash value.

9. System (401) for an infrastructure (601) which is arranged to carry out all steps of the method according to one of the preceding claims.

10. Method for increasing the security of a communication between an infrastructure-side system (401) of an infrastructure (601) and a motor vehicle system (300) of a motor vehicle 301), comprising the following steps: Agreeing (201) a shared secret by the vehicle-side system (300) with the infrastructure-side system (401), wherein in the case that the vehicle-side system (300) is the sender of user data for the infrastructure-side system (401) as the recipient of the user data, the method comprises the following steps: Calculating (203) a checksum over the payload data and the shared secret by the vehicle-side system (300), and Sending (205) the payload and the checksum to the infrastructure-side system (401) by the motor vehicle-side system (300), wherein in the case that the motor vehicle-side system (300) is the receiver of payload data for the motor vehicle-side system (300) from the infrastructure-side system (401) as the sender of the payload data, the method comprises the following steps: Receiving (207) the payload and a checksum from the infrastructure-side system (401) by the vehicle-side system (300), calculating (20) a checksum over the payload and the shared secret by the vehicle-side system (300) to determine a further checksum, Determining (211) based on the checksum and the further checksum by the motor vehicle system (300) whether the payload data may or may not be used on the motor vehicle side.

11. System (300) for a motor vehicle (301), wherein the system is configured to carry out all steps of the method according to claim 10.

12. Motor vehicle (301) comprising the system (300) according to claim 11.

13. A computer program (503) comprising instructions which, when the computer program (503) is executed by a computer, cause the computer to carry out a method according to one of claims 1 to 8 and / or 10.

14. A machine-readable storage medium (501) on which the computer program (503) according to claim 13 is stored.

Images