Method for increasing security of communication between infrastructure and motor vehicle
By establishing a shared secret and calculating a checksum between the infrastructure and the vehicle in the automated valet parking system, the communication security issue is resolved, enabling the legitimate use and efficient transmission of data, and enhancing the system's security and reliability.
Patent Information
- Application Number
- CN202480032304.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-05-16
- Filing Date
- 2024-05-16
- Publication Date
- 2025-12-12
AI Technical Summary
In automated valet parking systems, the security of communication between infrastructure and vehicles is difficult to guarantee, especially in the case of unencrypted communication, which poses a risk of data tampering and illegal use.
By agreeing on a common secret between the infrastructure-side system and the vehicle-side system, calculating a checksum, and using the common secret for verification during data transmission, the integrity and legitimate use of data can be ensured.
It improves the security of communication between infrastructure and motor vehicles, ensures that data is only used on legitimate motor vehicles, reduces the computational resource consumption for encryption and decryption, and enhances the reliability and security of communication.
Smart Images

Figure CN121128135A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to two methods for improving the security of communication between infrastructure-side systems of infrastructure and vehicle-side systems of motor vehicles, a system for infrastructure, a system for motor vehicles, a motor vehicle, a computer program, and a machine-readable storage medium. Background Technology
[0002] In Automated Valet Parking (AVP), vehicles drive autonomously within a parking lot. Infrastructure installed within the parking lot monitors the vehicle's surroundings to guide it through the parking area without collisions and with sufficient distance from other road users. A key requirement is that communication between the infrastructure and the vehicle be as secure as possible.
[0003] Patent application DE 10 2016 213145 A1 discloses a method for certifying motor vehicles.
[0004] Patent application DE 10 2012 222 562 A1 discloses a system for managing parking lots, which is used to transport vehicles from a starting point to a destination. Summary of the Invention
[0005] The objective upon which this invention is based can be viewed as providing a solution for improving the security of communication between the infrastructure-side system of an infrastructure and the vehicle-side system of a motor vehicle.
[0006] This task is solved by means of the subject matter protected by the independent claims. The advantageous configurations of the invention are the subject matter protected by the dependent claims.
[0007] According to a first aspect, a method is provided for improving the security of communication between an infrastructure-side system (especially an automated valet parking system) of infrastructure (especially a parking lot) and a vehicle-side system (especially an automated valet parking system) of a motor vehicle (especially an automated valet parking vehicle), the method comprising the following steps: The infrastructure-side system and the vehicle-side system agree on a shared secret; In the case where the infrastructure-side system is the sender of useful data for the vehicle-side system, which is the receiver of useful data, the method includes the following steps: The checksum is calculated using useful data and shared secrets through the infrastructure-side system; Useful data and checksums are sent to the vehicle-side system via the infrastructure-side system; Where the infrastructure-side system is the recipient of useful data for the infrastructure-side system from the vehicle-side system, which is the sender of useful data, the method includes the following steps: Receive useful data and checksums from the vehicle-side system through the infrastructure-side system; Another checksum is obtained by calculating a checksum using useful data and a shared secret through the infrastructure-side system; The infrastructure-side system determines whether useful data is permitted for use on the infrastructure side based on the checksum and the other checksum.
[0008] According to the second aspect, a system (especially an automated valet parking system) for infrastructure (especially parking lots) is provided, which is configured to perform all the steps of the method according to the first aspect.
[0009] According to a third aspect, a method is provided for improving the security of communication between an infrastructure-side system (especially an automated valet parking system) of infrastructure (especially a parking lot) and a vehicle-side system (especially an automated valet parking system) of a motor vehicle (especially an automated valet parking vehicle), the method comprising the following steps: The vehicle-side system and the infrastructure-side system agree on a shared secret; Where the vehicle-side system is the sender of useful data for the infrastructure-side system, which is the receiver of useful data, the method includes the following steps: The verification is calculated using useful data and shared secrets through the vehicle-side system; Useful data and checksums are sent to the infrastructure-side system via the vehicle-side system; Wherein, in the case that the vehicle-side system is the sender of useful data for the vehicle-side system from the infrastructure-side system, which is the sender of useful data, the method includes the following steps: Receive useful data and checksums from the infrastructure-side system through the vehicle-side system; Another checksum is obtained by calculating a checksum using useful data and a shared secret through the vehicle-side system; The vehicle-side system determines whether useful data is permitted for use on the vehicle side based on the checksum and the other checksum.
[0010] According to the fourth aspect, a system for motor vehicles (especially an automated valet parking system) is provided, which is configured to perform all the steps of the method according to the third aspect.
[0011] According to the fifth aspect, a motor vehicle (especially an automated valet parking motor vehicle) is provided, which includes the system according to the fourth aspect.
[0012] According to a sixth aspect, a computer program is provided that includes instructions, which, when executed by a computer (e.g., a system according to the second aspect and / or the fourth aspect), cause the computer to perform a method according to the first aspect and / or the third aspect.
[0013] According to a seventh aspect, a machine-readable storage medium is provided on which a computer program according to a sixth aspect is stored.
[0014] This invention is based on and incorporates the following understanding: agreeing on a common secret between the vehicle-side system and the infrastructure-side system, for example, agreeing on a common cryptographic key when using a key exchange method.
[0015] Furthermore, according to the scheme described herein, for useful data obtained by one of the two systems (i.e., the infrastructure-side system and the vehicle-side system) for the other system within those two systems, the system obtaining the useful data will calculate a checksum using a common secret. In other words, the checksum is calculated using the useful data and the common secret.
[0016] For example, the secret is appended to the useful data, and then the checksum is calculated over the entire dataset. Example: 100 bits of useful data, 32 bits of secret → checksum calculated over all 132 bits. The secret in the dataset can be located, for example, before or after the useful data.
[0017] For example, checksum calculation involves hashing the useful data based on a common secret, or, where a common secret is used, by doing so. For instance, the common secret and the useful data constitute a common dataset, which is then hashed. Specifically, the hash value is calculated using the useful data and the common secret.
[0018] As a result of hashing, a hash value becomes available, which is sent, for example, appended to useful data.
[0019] Typically, a checksum is available as a result of the checksum calculation, and this checksum is sent along with the useful data.
[0020] Therefore, on the receiving side, useful data and a checksum are received from the corresponding system via the corresponding system. When using the received checksum, this useful data is verified as follows: the system calculates another checksum via the useful data and a secret in the same manner as the sending system. Therefore, this specifically implies the existence of the same predetermined checksum calculation rules, by which the corresponding checksums are calculated respectively on the vehicle-side system (i.e., via the vehicle-side system) and on the infrastructure side (i.e., via the infrastructure-side system).
[0021] For example, if the useful data has not been altered, the system receiving the useful data will calculate another checksum that matches the received checksum as the result of the calculation of the other checksum. If there is a difference between the checksum calculated by the system sending the useful data and the checksum calculated by the system receiving the useful data (i.e., the other checksum), the system receiving the useful data may, for example, assume that the useful data has been tampered with, or (if the receiver is a vehicle-side system) the useful data was determined for another vehicle. This is because, in the latter case, the infrastructure-side system uses a secret different from the secret agreed upon by the vehicle-side system and the infrastructure-side system for calculating the checksum.
[0022] Therefore, for example, multiple vehicles may receive useful data for a specific vehicle. However, only that specific vehicle will calculate a checksum that matches the received checksum (i.e., the checksum belonging to the useful data or sent along with the useful data). This is because the secret used to calculate the checksum is known only to the infrastructure-side system and the vehicle-side system of that specific vehicle.
[0023] Therefore, the security of communication between infrastructure and motor vehicles can be improved efficiently and advantageously. In particular, useful data communication between motor vehicles and infrastructure can be carried out advantageously, for example, in an unencrypted manner, which saves the computational resources required for encryption and decryption.
[0024] Furthermore, it is thus possible to determine, in a favorable manner, whether the received useful data is determined for that vehicle at the vehicle side. If so, this useful data can be used at the vehicle side. If not, this useful data is not used at the vehicle side. Therefore, driving instructions not determined for that vehicle will not be executed at the vehicle side, which can effectively improve safety.
[0025] Therefore, the following technical advantages are particularly achieved: for example, within the scope of automated valet parking processes, communication between automated valet parking vehicles and infrastructure can be efficiently improved. Furthermore, it is also possible to efficiently ensure, in an advantageous manner, that useful data for a particular vehicle can only be used by that specific vehicle and not by other vehicles.
[0026] For example, if a checksum matches another checksum, it is determined that the useful data has been transmitted tamper-proofly through the communication channel between the two systems. In this case, it is determined, for example, that the useful data is permitted for use on the receiving side.
[0027] For example, if a checksum does not match another checksum, it is determined that the useful data has been transmitted tampered with through the communication channel between the two systems. In this case, it can be determined, for example, that the useful data is not permitted for use at the receiving end.
[0028] For example, a system receiving useful data may be configured to compare a checksum with another checksum, and based on this comparison, determine whether the useful data is permitted for use. For instance, if the checksum matches another checksum, the system receiving the useful data determines that the useful data is permitted for use. Conversely, if the checksum does not match another checksum, the system receiving the useful data determines that the useful data is not permitted for use.
[0029] For example, if the checksum matches another checksum, the system receiving the useful data determines not to discard the useful data. Conversely, if the checksum does not match another checksum, the system receiving the useful data determines to discard the useful data, thus discarding the useful data, for example, through the system receiving the useful data.
[0030] Furthermore, this scheme ensures that components involved in communication between infrastructure and vehicles will not tamper with transmitted useful data due to errors in their programming. If useful data is protected solely by checksums, any component could potentially alter the data and generate a new checksum. This is especially true if a component malfunctions and does not operate as intended. In this case, the component only knows the method for calculating the checksum—which cannot be ruled out.
[0031] By incorporating a shared secret into the checksum, it is reliably excluded that the components involved in the communication are able to set the correct checksum because they are certain they do not know the secret.
[0032] In one embodiment of the method according to the first aspect, the agreement on the common secret includes encrypting the transmission of the common secret to the vehicle-side system via the infrastructure-side system, or encrypting the reception of the common secret from the vehicle-side system via the infrastructure-side system.
[0033] For example, this achieves the following technical advantage: the ability to efficiently agree on a secret. In particular, encryption achieves the following technical advantage: making it difficult or impossible for third parties and / or components involved in the communication to obtain the shared secret.
[0034] In one embodiment of the method according to the first aspect, a random number is obtained through the infrastructure-side system as a common secret, and the random number is encrypted and sent to the vehicle-side system.
[0035] For example, this achieves the following technical advantages: it allows for the efficient acquisition and agreement of common secrets.
[0036] In one embodiment of the method according to the first aspect, a common secret is agreed upon by means of a key exchange method, such that the common secret is a common cryptographic key.
[0037] By using key exchange methods, the following technical advantages are achieved: even if communication between the vehicle-side system and the infrastructure-side system is eavesdropped on by a third party, the shared cryptographic key cannot be deduced from the eavesdropping. Therefore, a shared secret can be efficiently agreed upon even via un-eavesdropping (i.e., unencrypted) communication channels. Thus, for example, communication between the vehicle-side system and the infrastructure-side system can be unencrypted, thereby saving the computational overhead required for encryption on both sides.
[0038] In one embodiment of the method according to the first aspect, a common secret (especially a common cryptographic key or random number) is agreed upon when using a broadcast communication method (especially a V2X protocol).
[0039] For example, this achieves the following technical advantages: shared secrets can be efficiently agreed upon. In particular, using V2X protocols offers the following technical advantages: standardized protocols can be used for communication between infrastructure-side systems and vehicle-side systems.
[0040] In one embodiment of the method according to the first aspect, a common cryptographic key is agreed upon by means of the Diffie-Hellman (DH) method or the Elliptic-Curve-Diffie-Hellman (ECDH) method.
[0041] For example, this achieves the following technical advantage: a particularly suitable key exchange method is used.
[0042] In one embodiment of the method according to the first aspect, the useful data includes one or more of the following useful data: driver's license, current time, time synchronization request, time synchronization response, vehicle attribute confirmation (especially size, interface version, etc.).
[0043] For example, this achieves the following technical advantage: it enables the secure protection of particularly meaningful and useful data.
[0044] Interface version refers to the version number of the interface. This interface is the interface between the vehicle and the infrastructure, specifically the interface between the vehicle-side system and the infrastructure-side system. On this interface—depending on the version—for example, a driver's license may be described differently or its meaning may change. This allows for the possibility of further improvements to the interface. For example, in interface version 1.0, the driver's license includes instructions for both directions of travel. In version 2.0, it may only be used for the required direction of travel (e.g., to save data). The infrastructure will then know which direction the vehicle should move.
[0045] The important thing now is for vehicles and infrastructure to agree on the version of their interfaces from the outset so that the data can be interpreted correctly.
[0046] In one embodiment of the method according to the first aspect, the calculation of the checksum includes calculating a cyclic redundancy check (CRC checksum) or a cryptographic hash value.
[0047] For example, this achieves the following technical advantage: checksum calculation can be performed with particularly high efficiency. In particular, it achieves the following technical advantage: since checksums (especially CRC checksums) can be calculated very simply, almost no computational resources are required.
[0048] CRC stands for "Cycle Redundancy Check".
[0049] In one embodiment of the method according to the third aspect, the agreed common secret includes encrypting the transmission of the common secret to the infrastructure side system via the vehicle-side system, or encrypting the reception of the common secret from the infrastructure side system via the vehicle-side system.
[0050] For example, this achieves the following technical advantage: the ability to efficiently agree on secrets. Encryption, in particular, achieves the following technical advantage: making it difficult or impossible for third parties and / or components involved in the communication to eavesdrop on the shared secret.
[0051] In one embodiment of the method according to the third aspect, a random number is obtained through the vehicle-side system as a common secret, and the random number is encrypted and sent to the infrastructure-side system.
[0052] For example, this achieves the following technical advantages: it allows for the efficient identification and agreement of shared secrets.
[0053] In one embodiment of the method according to the third aspect, a common secret is agreed upon by means of a key exchange method, such that the common secret is a common cryptographic key.
[0054] In one embodiment of the method according to the third aspect, a common secret (especially a common cryptographic key or random number) is agreed upon when using a broadcast communication method (especially a V2X protocol).
[0055] In one embodiment of the method according to the third aspect, a common cryptographic key is agreed upon using the Diffie-Hellman (DH) method or the Elliptic Curve Diffie-Hellman (ECDH) method.
[0056] In one embodiment of the method according to the third aspect, the useful data includes one or more of the following useful data: driver's license, current time, time synchronization request, time synchronization response, vehicle attribute confirmation (especially size, interface version, etc.).
[0057] In one embodiment of the method according to the third aspect, the calculation of the checksum includes calculating a cyclic redundancy check (CRC checksum) or a cryptographic hash value.
[0058] The description relating to the method according to the first aspect applies in a similar manner to the method according to the third aspect, and vice versa. The technical functions of the method according to the first aspect are derived in a similar manner from the corresponding technical functions of the method according to the third aspect, and vice versa. This means that the features of the method according to the first aspect are derived in a similar manner from the corresponding features of the method according to the third aspect, and vice versa.
[0059] The system according to the second aspect is configured, for example, in programming technology, to execute a computer program that includes instructions that, when executed by a computer, cause the computer to perform the method according to the first aspect.
[0060] For example, the system according to the fourth aspect is technically configured to execute a computer program that includes instructions that, when executed by a computer, cause the computer to perform the method according to the third aspect.
[0061] The method described in the first aspect is, for example, a computer-implemented method.
[0062] The third approach is, for example, a computer-implemented method.
[0063] The description relating to the method according to the first aspect applies in a similar manner to the system according to the second aspect, and vice versa. This means that the technical functions and features of the system according to the second aspect are derived in a similar manner from the corresponding technical functions and features of the method according to the first aspect, and vice versa.
[0064] The descriptions relating to the method according to the third aspect are applied in a similar manner to the system according to the fourth aspect, and vice versa. This means that the technical functions and technical features of the system according to the fourth aspect are derived in a similar manner from the corresponding technical functions and technical features of the method according to the third aspect, and vice versa.
[0065] The system in this specification is, for example, an automated valet parking system, that is, especially a vehicle-side automated valet parking system or an infrastructure-side automated valet parking system.
[0066] In this manual, a motor vehicle is, for example, an automated valet parking vehicle.
[0067] In this specification, a motor vehicle is located inside the infrastructure.
[0068] Infrastructure in the sense of this specification includes, for example, parking lots, railway stations, freight stations, ports, freight ports, car terminals, ferry terminals, factories, automobile manufacturing plants, and automobile production workshops.
[0069] The term "motor vehicle" as used in this specification refers to, for example, a motor vehicle that is at least highly automated. This means that the motor vehicle is specifically configured to operate at least highly automated.
[0070] Systems for motor vehicles are configured, for example, to guide motor vehicles with at least a high degree of automation.
[0071] The abbreviation "AVP" stands for "Automated Valet Parking," which in German can be translated as "automatischerParkservice" (automatic parking service). An automated valet parking process includes, for example, the highly automated guidance of the valet vehicle from the drop-off point (also known as the delivery location) to the parking position, and, for example, the highly automated guidance of the valet vehicle from the parking position to the pick-up point (also known as the pick-up point). At the delivery location (i.e., the drop-off point), the driver of the valet vehicle delivers the vehicle to initiate the automated valet parking process. At the pick-up point (i.e., the pick-up point), the vehicle is retrieved after the automated valet parking process is completed. Therefore, the automated valet parking process begins, in particular, at the drop-off point. The pick-up point and drop-off point may be the same or different.
[0072] Therefore, an automated valet parking vehicle is a motor vehicle that can participate in the automated valet parking process.
[0073] The automated valet parking process is performed on the infrastructure side using the exemplary automated valet parking system according to the second aspect or by means of the exemplary automated valet parking system according to the second aspect, and on the automated valet parking vehicle side using the exemplary automated valet parking system according to the fourth aspect or by means of the exemplary automated valet parking system according to the fourth aspect.
[0074] The automated valet parking process can be one of the following automated valet parking types: Automated Valet Parking Type 1, Automated Valet Parking Type 2, and Automated Valet Parking Type 3. However, the automated valet parking type can be switched within the automated valet parking process. This means, for example, that part of the automated valet parking process is executed according to Automated Valet Parking Type 1, and another part of the automated valet parking process is executed according to Automated Valet Parking Type 2 or Automated Valet Parking Type 3. This means, for example, that the automated valet parking process can be divided into multiple sub-automated valet parking processes, which are executed according to Automated Valet Parking Type 1, Automated Valet Parking Type 2, or Automated Valet Parking Type 3, respectively.
[0075] Type 1 of automated valet parking indicates an automated valet parking process centered on the vehicle. The primary responsibility for the automated valet parking process lies with the vehicle being parked (i.e., the vehicle-side automated valet parking system).
[0076] Type 2 of automated valet parking refers to an infrastructure-centric automated valet parking process. The primary responsibility for the automated valet parking process lies with the infrastructure (i.e., the infrastructure-side automated valet parking system).
[0077] Type 3 of automated valet parking indicates an automated valet parking process shared by both the vehicle and the infrastructure. Here, the primary responsibility for the automated valet parking process is shared between the automated valet parking vehicle (i.e., the vehicle-side automated valet parking system) and the infrastructure-side automated valet parking system.
[0078] The automated valet parking process includes the following operations or functions: 1. Determine the target location within the parking lot for vehicles using automated valet parking.
[0079] 2. Plan the route from the starting point, which includes the parking area, to the destination.
[0080] 3. Detect objects and / or events and respond accordingly to detected objects and / or events.
[0081] 4. Clearly define the location of vehicles using automated valet parking systems within the parking lot.
[0082] 5. Calculate the target trajectory of the automated valet parking vehicle based on the planned route.
[0083] 6. Based on the calculated target trajectory, control the lateral and longitudinal guidance of the vehicle in the automated valet parking system.
[0084] The table below illustrates whether these operations or functions are performed by the automated valet parking vehicle (i.e., the vehicle-side automated valet parking system) or the infrastructure-side automated valet parking system, depending on the type of automated valet parking. Here, "I" represents "infrastructure" (i.e., infrastructure-side automated valet parking system), and "K" represents "automated valet parking vehicle." Thus, "I" indicates that the process is performed by the automated valet parking system, and "K" indicates that the process is performed by the vehicle-side automated valet parking system.
[0085] Therefore, the table above specifies whether each function is performed via the infrastructure (i.e., via the infrastructure-side automated valet parking system) or via the automated valet vehicle (i.e., via the vehicle-side automated valet parking system) for each type of automated valet parking. In some cases, the function can be configured to be performed via both the infrastructure-side automated valet parking system and the automated valet vehicle.
[0086] For object and event detection in Automated Valet Parking Type 1, it can be optionally configured that, in addition to the Automated Valet Parking System on the vehicle side, the Infrastructure-side Automated Valet Parking System can also perform this function.
[0087] The automated valet parking types 1, 2 and 3 described herein are further described in detail in ISO standard 23374-1:2021(E).
[0088] Automated valet parking vehicles are those that are at least highly automated. These vehicles are configured for at least highly automated guidance. According to the German Federal Highway Research Institute (BASt), highly automated guidance corresponds to automation level 4.
[0089] Motor vehicles (especially automated valet parking vehicles) being configured for at least highly automated guidance includes not only the case where the vehicle is configured for highly automated guidance, but also the case where it is configured for fully automated guidance. According to the BASt definition, fully automated guidance corresponds to automation level 5.
[0090] Highly automated guidance refers to the automatic control of a vehicle's longitudinal and lateral guidance within specific scenarios (e.g., driving on a highway, driving in a parking lot, overtaking objects, driving within a lane marked by lane markings) for a certain period of time. The driver does not need to manually control the vehicle's longitudinal and lateral guidance. The driver does not need to continuously monitor the automatic control of longitudinal and lateral guidance to intervene manually when necessary. When needed, a takeover request is automatically issued to the driver to take over control of longitudinal and lateral guidance, especially with sufficient time leeway. Therefore, the driver needs to be potentially able to take over control of longitudinal and lateral guidance. The boundaries of automatic control of longitudinal and lateral guidance are automatically identified. In highly automated guidance, it is not possible to automatically achieve a state of risk minimization in all initial scenarios.
[0091] Fully automated guidance refers to the automatic control of a vehicle's longitudinal and lateral guidance in specific scenarios (e.g., driving on a highway, driving in a parking lot, overtaking objects, driving within a lane marked by lane markings). The driver does not need to manually control the vehicle's longitudinal and lateral guidance. The driver does not need to monitor the automatic control of longitudinal and lateral guidance to intervene manually when necessary. Before the automatic control of lateral and longitudinal guidance ends, a request is automatically issued to the driver to take over driving tasks (controlling the vehicle's lateral and longitudinal guidance), especially with sufficient time margin. If the driver does not take over driving tasks, the vehicle is automatically guided to a state of minimum risk. The limits of automatic control of lateral and longitudinal guidance are automatically identified. The system can automatically return to the state of minimum risk in all scenarios.
[0092] Motor vehicles may include, for example, one or more environmental sensors. These environmental sensors may also be referred to as motor vehicle environmental sensors. These environmental sensors are included, for example, by a motor vehicle side system. A motor vehicle environmental sensing system may include, for example, one or more such environmental sensors.
[0093] The system according to the second aspect includes, for example, one or more environmental sensors spatially distributed within the infrastructure (especially within a parking lot). These environmental sensors may be referred to as infrastructure environmental sensors, for example. An infrastructure environmental sensing system includes, for example, one or more such infrastructure environmental sensors.
[0094] Environmental sensors (i.e., vehicle environmental sensors or infrastructure environmental sensors) include, for example, one of the following: radar sensors, lidar sensors, image sensors (especially image sensors for cameras, such as image sensors for stereo cameras), ultrasonic sensors, magnetic field sensors, and infrared sensors.
[0095] The implementation methods and examples described herein can be combined with each other in any way, even if not explicitly stated otherwise.
[0096] When a system based on the second aspect is implemented in infrastructure (especially parking lots), the system based on the second aspect can be called an infrastructure-side system.
[0097] When the system according to the fourth aspect is implemented in a motor vehicle, the system according to the fourth aspect may be referred to as a motor vehicle side system.
[0098] The Diffie-Hellman method, in particular, requires two parameters that can be predefined and publicly known. For example, these parameters can be agreed upon in advance or described in a standard.
[0099] The parameters are: a large, suitable prime number p and a so-called generator g. For example, for the Diffie-Hellman method with a large 32-bit number, the suitable parameters are: p = 4294967087 = 2^32 - 209 = 0xffffff2f and g=5 or g=10.
[0100] For example, for the Diffie-Hellman method with a large 64-bit number, the appropriate parameters are: p = 18446744073709550147 = 2^64 - 1469 = 0xfffffffffffffa43 and g=2 or g=5.
[0101] Here, "^" represents exponentiation, that is, 2 to the power of 32 or 2 to the power of 64.
[0102] The parameters described here are the largest suitable prime number that can still be represented with a specified number of bits, and two possible suitable generators. A prime number p is suitable when (p-1) / 2 is also a prime number. Generally, this means that for a secret of n bits, the parameter p is, for example, the largest prime number that can still be represented with a specified number of bits (here, n bits) that satisfies these properties.
[0103] The methods according to the first aspect include, for example, obtaining useful data for the vehicle-side system through the infrastructure-side system.
[0104] The methods in the third aspect include, for example, obtaining useful data for the infrastructure-side system through the vehicle-side system. Attached Figure Description
[0105] The present invention will now be described in more detail based on preferred embodiments. Herein lies: Figure 1 A flowchart of the method according to the first aspect is shown; Figure 2 A flowchart of the method according to the third aspect is shown; Figure 3 The system according to the fourth aspect is shown; Figure 4 The system according to the second aspect is shown; Figure 5 A machine-readable storage medium according to the seventh aspect is shown; Figure 6 A parking lot is shown.
[0106] In the following text, the same reference numerals may be used for the same features. Detailed Implementation
[0107] Figure 1 A flowchart is shown of a method for improving the security of communication between an infrastructure-side system of infrastructure and a vehicle-side system of a motor vehicle, the method comprising the following steps: The infrastructure-side system and the vehicle-side system agree on 101 shared secrets; Where the infrastructure-side system is the sender of useful data for the vehicle-side system, which is the receiver of useful data, the method includes the following steps: The 103 checksum is calculated via useful data and shared secrets through the infrastructure-side system; Useful data and verification codes are sent from the infrastructure-side system to the vehicle-side system via 105. Where the infrastructure-side system is the recipient of useful data for the infrastructure-side system from the vehicle-side system, which is the sender of useful data, the method includes the following steps: Receive 107 useful data and checksums from the vehicle-side system through the infrastructure-side system; The infrastructure-side system calculates a 109 checksum using useful data and shared secrets to obtain another checksum; The infrastructure-side system determines, based on the checksum and the other checksum, whether the useful data is permitted for use on the infrastructure side, or whether the useful data has been transmitted untampered through the communication channel between the two systems.
[0108] Figure 2 A flowchart is shown of a method for improving the security of communication between an infrastructure-side system of infrastructure and a vehicle-side system of a motor vehicle, the method comprising the following steps: The two systems, the vehicle-side system and the infrastructure-side system, agreed on 201 common secrets. Where the vehicle-side system is the sender of useful data for the infrastructure-side system, which is the receiver of useful data, the method includes the following steps: The 203 checksum is calculated via useful data and shared secrets through the vehicle-side system. The useful data and verification code are sent from the vehicle-side system to the infrastructure-side system via 205. Where the vehicle-side system is the receiver of useful data for the vehicle-side system from the infrastructure-side system, which is the sender of useful data, the method includes the following steps: Receive 207 useful data and checksums from the infrastructure-side system via the vehicle-side system; The vehicle-side system calculates a checksum using useful data and shared secrets to obtain another checksum; The vehicle-side system determines, based on the checksum and the other checksum, whether the useful data is permitted for use on the vehicle side or whether the useful data has been transmitted untampered through the communication channel between the two systems.
[0109] Figure 3 A system 300 according to the fourth aspect is shown, which is included in or implemented therein by a motor vehicle 301 according to the fifth aspect. The system 300 is configured to perform all the steps of the method according to the third aspect.
[0110] The vehicle-side system 300 includes a wireless communication interface 305 configured to communicate with an infrastructure-side system (not shown).
[0111] Communication in the sense of this specification includes sending and receiving.
[0112] System 300 also includes a processor device 307 having one or more processors (not shown). For example, processor device 307 is configured to perform calculations of the common secret and checksum, as well as the computational steps required to determine it.
[0113] Figure 4 A system 401 according to the second aspect is shown. The system 401 is configured to perform all the steps of the method according to the first aspect.
[0114] For example, system 401 includes a camera 403, which includes an image sensor 405. System 401 may also include a radar sensor 407.
[0115] These environmental sensors are spatially distributed within the infrastructure (particularly a parking lot, not shown) and each detects a specific area of the infrastructure. The environmental sensor data based on these detections is output to a data processing device 409, which processes the environmental sensor data and, for example, determines infrastructure auxiliary data based on the processing to assist at least highly automated vehicles within the infrastructure (particularly within the scope of automated valet parking processes) in a range of at least highly automated driving. Infrastructure auxiliary data is an example of useful data.
[0116] It should be noted here that "instead of" or "attached to" are used interchangeably with "in addition to". Figure 4 The environmental sensors shown can be further modified to include more or fewer environmental sensors and / or other environmental sensors.
[0117] In addition, the infrastructure-side system 401 also includes a wireless communication interface 411 configured to communicate with one or more (especially at least highly automated) motor vehicles located within the infrastructure (especially parking lots).
[0118] For example, system 401 includes multiple such wireless communication interfaces 411, which are spatially distributed within the infrastructure to achieve sufficient wireless coverage.
[0119] The data processing apparatus 409 may include, for example, one or more servers, one or more of which may be implemented in a cloud infrastructure.
[0120] In one embodiment not shown, system 401 does not include an infrastructure environment sensor. In this case, the infrastructure environment sensor is already part of the infrastructure.
[0121] Figure 5 A machine-readable storage medium 501 according to the seventh aspect is shown, on which a computer program 503 according to the sixth aspect is stored.
[0122] Figure 6 An example of an infrastructure is shown, in which parking lot 601 is implemented. Figure 4 System 401, specifically the automated valet parking system, exists within this parking lot. Figure 3 Motor vehicle 301, for example, is an automated valet parking vehicle, and another motor vehicle 603 is present in the parking lot.
[0123] Motor vehicle 301 needs to perform the automated valet parking process; therefore, motor vehicle 301 may also be referred to below as an automated valet parking vehicle. Within the scope of the automated valet parking process, it is essential that useful data determined solely by this automated valet parking vehicle can only be used by this automated valet parking vehicle, i.e., it cannot be used by another motor vehicle 603, for example. This can be achieved advantageously through the scheme described herein.
[0124] Thus, specifically, the infrastructure-side automated valet parking system 401 and the vehicle-side system 300 agree on a common cryptographic key as a shared secret, for example, using a key exchange method. This means that the two systems 300 and 401 agree on a common cryptographic key known only to each other using a key exchange method. Alternatively, the infrastructure-side automated valet parking system 401 can encrypt and send a random number as a shared secret to the vehicle-side system 300.
[0125] The infrastructure-side automated valet parking system 401 obtains useful data for vehicle 301. This useful data includes, for example, driving instructions that should only be executed by vehicle 301 and not by another vehicle 603. The infrastructure-side automated valet parking system 401 calculates a checksum using the useful data and a common secret. Then, the infrastructure-side automated valet parking system 401 sends the calculated checksum along with the useful data to the vehicle-side automated valet parking system 300. The vehicle-side automated valet parking system 300 calculates another checksum using the received useful data and a common secret in the same manner as the infrastructure-side automated valet parking system 401. Only when this second checksum matches the received checksum will the vehicle-side automated valet parking system 401 determine that the useful data is permitted for use on the vehicle side. For example, it then permits the execution of the driving instruction.
[0126] Even if another vehicle 603 were to eavesdrop on the communication between the infrastructure-side automated valet parking system 401 and the vehicle-side system 300, it still wouldn't be able to calculate the same (alternate) checksum (which is calculated by the vehicle-side system 300) because the other vehicle 603 wouldn't know the common secret (the common cryptographic key) and couldn't easily calculate it from the eavesdropped communication. Therefore, the other vehicle-side automated valet parking system (not shown) of the other vehicle 603 would determine that this useful data is not permitted on the vehicle side. Consequently, the driving instruction will not be executed by the other vehicle 603.
[0127] The vehicle-side system 300 can be the sender of useful data for the infrastructure-side automated valet parking system 401, which is the receiver of useful data. Accordingly, the foregoing description—as it relates to the infrastructure-side automated valet parking system 401, which is the sender of useful data for the vehicle-side system 300, which is the receiver of useful data—is applied in a similar manner.
[0128] Therefore, the necessary communication between the infrastructure-side automated valet parking system and the vehicle-side system can be standardized in an advantageous manner without sacrificing safety. Thus, for example, one or more V2X protocols can be used for this communication.
[0129] When using the V2X protocol, the communication is no longer conducted separately and encrypted (1:1 communication) between the infrastructure (i.e., the infrastructure-side automated valet parking system) and the automated valet parking vehicle (i.e., the vehicle-side automated valet parking system). Instead, the communication is public and can be read by any participant.
[0130] In typical V2X applications, this is a meaningful approach. For example, when driving on a highway, each vehicle can transmit its current actual speed and location to all other vehicles, which can then be used for various functions (e.g., automatic deceleration when congestion occurs).
[0131] This communication method is called broadcasting: one participant sends its message, and all other participants read and use the sent data when needed. Therefore, it is always a 1:n communication.
[0132] The scheme described herein, for example, establishes a shared secret between the infrastructure (i.e., the infrastructure-side system) and the vehicle (i.e., the vehicle-side system). Specifically, the infrastructure-side system and the vehicle-side system agree on a common cryptographic key, for example, through a key exchange method. Here, the Diffie-Hellman method can be used, for example. The key exchange process can be conducted publicly, for example, while an eavesdropper cannot compute the shared secret.
[0133] This shared secret (i.e., a shared cryptographic key or random number) is known only to the infrastructure and the vehicle.
[0134] Therefore, for example, it is ensured that, especially in the presence of multiple motor vehicles, only the motor vehicle using the useful data determined for that motor vehicle is thus, for example, carrying out the driving instruction.
[0135] Therefore, for example, even if some vehicles are able to monitor the communication between the infrastructure and the automated valet parking vehicle to be controlled, safe automated valet parking operations can still be achieved.
[0136] In summary, therefore, it is specifically set that the infrastructure and the automated valet parking vehicles to be controlled share common secrets.
[0137] For example, the infrastructure provides a random number as a secret to the vehicle at the start. This transmission can be encrypted so that other automated valet parking vehicles cannot know the secret.
[0138] Alternatively, a common secret can be agreed upon through a cryptographic key exchange method (such as the Diffie-Hellman method).
[0139] If the infrastructure now needs to send useful data to the vehicle, the infrastructure calculates a CRC checksum, for example, via the useful data and a shared secret.
[0140] The infrastructure then sends the useful data and the calculated CRC checksum to the vehicle, but not the common secret.
[0141] Therefore, someone who is eavesdropping but does not know the shared secret cannot calculate the correct CRC checksum from the useful data.
[0142] On the vehicle side, upon receiving useful data, the CRC checksum is recalculated by supplementing the received useful data with a known secret and then calculating the CRC checksum using the useful data containing the supplemented secret. If the calculated CRC checksum matches the received CRC checksum, then the useful data is identified as belonging to that vehicle and has been transmitted correctly. Otherwise, the vehicle-side system discards this useful data. This ensures, for example, that only valid driving instructions are followed on the vehicle side.
[0143] Another example will further illustrate the scheme described in this article.
[0144] The infrastructure-side system includes a first server (server 1) and a second server (server 2). The vehicle-side system includes a first electronic control unit (ECU) (ECU1) and a second electronic control unit (ECU2).
[0145] The first server retrieves useful data for the vehicle-side system, and this useful data can be transmitted as follows: Server 1—Useful Data → Server 2—Encrypted Channel → ECU1—Useful Data → ECU2 The communication between server 2 in the infrastructure and ECU1 in the vehicle is encrypted and therefore protected against attackers.
[0146] However, within the infrastructure (inaccessible to attackers), useful data is generated on server 1 and transmitted to server 2 in an unencrypted manner.
[0147] In a motor vehicle, ECU1 decrypts the received useful data and then transmits it to ECU2 in an unencrypted manner.
[0148] Therefore, useful data may now be on an unencrypted channel or tampered with during encryption / decryption, for example, due to errors in the encryption software. If the software is aware of the algorithm, it may also incorrectly append a valid CRC checksum to the data.
[0149] The advantages of the solution described in this article are particularly evident in the following aspects: 1) ECU2 can reliably determine that it has received tamper-proof and useful data from server 1—no component in the communication channel can calculate the correct CRC checksum; 2) This protection requires almost no computational resources because the CRC can be calculated very simply. For example, ECU2 could be an ESP (braking system), which does not have the computational capabilities required for cryptography.
Claims
1. A method for improving the security of communication between an infrastructure-side system (401) of infrastructure (601) and a vehicle-side system (300) of a motor vehicle (301), the method comprising the steps of: The infrastructure-side system (401) and the vehicle-side system (300) agree (101) to maintain a shared secret; Wherein, when the infrastructure-side system (401) is the sender of useful data for the vehicle-side system (300) which is the receiver of useful data, the method includes the following steps: The system (401) verifies the data using the useful data and the shared secret computation (103); The useful data and the checksum are sent (105) to the vehicle side system (300) through the infrastructure side system (401). Wherein, in the case that the infrastructure-side system (401) is the receiver of useful data for the infrastructure-side system (401) from the vehicle-side system (300) which is the sender of useful data, the method includes the following steps: The useful data and checksum are received (107) from the vehicle-side system (300) via the infrastructure-side system (401); Another checksum is obtained by checking the useful data and the common secret calculation (109) through the infrastructure-side system (401); The infrastructure-side system (401) determines (111) whether the useful data is allowed to be used on the infrastructure side based on the checksum and the other checksum.
2. The method according to claim 1, wherein, The agreed-upon common secret includes transmitting the common secret encrypted from the infrastructure-side system (401) to the vehicle-side system (300), or receiving the common secret encrypted from the vehicle-side system (300) through the infrastructure-side system (401).
3. The method according to claim 2, wherein, The infrastructure-side system (401) generates a random number as the common secret, and the random number is encrypted and sent to the vehicle-side system (300) through the infrastructure-side system (401).
4. The method according to claim 1, wherein, The common secret is agreed upon using a key exchange method, such that the common secret is a common cryptographic key.
5. The method according to claim 4, wherein, The common cryptographic key is agreed upon using the Diffie-Hellman (DH) method or the Elliptic Curve Diffie-Hellman (ECDH) method.
6. The method according to any one of the preceding claims, wherein, The useful data includes one or more of the following: driver's license, current time, time synchronization request, time synchronization response, vehicle attribute confirmation, especially size, interface version, etc.
7. The method according to any one of the preceding claims, wherein, The shared secret is agreed upon when using broadcast communication methods, especially the V2X protocol.
8. The method according to any one of the preceding claims, wherein, The calculation of the checksum includes calculating the cyclic redundancy check (CRC checksum) or the cryptographic hash value.
9. A system (401) for infrastructure (601), said system being configured to perform all the steps of the method according to any one of the preceding claims.
10. A method for improving the security of communication between an infrastructure-side system (401) of infrastructure (601) and a vehicle-side system (300) of a motor vehicle (301), the method comprising the steps of: The vehicle-side system (300) and the infrastructure-side system (401) agree to maintain a shared secret (201); Wherein, in the case that the vehicle-side system (300) is the sender of useful data for the infrastructure-side system (401) which is the receiver of useful data, the method includes the following steps: The system is verified by the vehicle-side system (300) via the useful data and the common secret calculation (203); The useful data and the checksum are sent (205) to the infrastructure side system (401) via the vehicle side system (300). Wherein, in the case that the vehicle-side system (300) is the receiver of useful data for the vehicle-side system (300) from the infrastructure-side system (401) which is the sender of useful data, the method includes the following steps: The useful data and checksum are received (207) from the infrastructure-side system (401) via the vehicle-side system (300); Another checksum is obtained by checking the useful data and the common secret calculation (20) through the vehicle side system (300); The vehicle-side system (300) determines (211) whether the useful data is permitted to be used on the vehicle side based on the checksum and the other checksum.
11. A system (300) for a motor vehicle (301), wherein, The system is configured to perform all the steps of the method according to claim 10.
12. A motor vehicle (301) comprising the system (300) according to claim 11.
13. A computer program (503) comprising instructions that, when executed by a computer, cause the computer to perform the method according to claims 1 to 8 and / or 10.
14. A machine-readable storage medium (501) on which a computer program (503) according to claim 13 is stored.
Citation Information
Patent Citations
System for managing parking spaces in e.g. public park for transferring vehicle from start to target position, has central processing unit to generate speed control signals and pass to transfer unit for transmission to vehicle
DE102012222562A1
Method and devices for authenticating a motor vehicle
DE102016213145A1