Methods for coupling authentication tools with vehicles

Abstract

The present invention relates to a method for coupling an authentication tool, particularly with a vehicle, wherein the authentication tool (12) communicates with a controller (32), particularly of a vehicle (10), for authorization, wherein at least one coupling is established if the authentication tool (12) is verified to be authoritative to the controller (32) by using at least one authentication message (50, 52, 56), particularly a password (50) and / or verification (52) and / or auxiliary information (56), wherein, for particularly initial coupling, the authentication message (50, 52, 56) can be generated by a server (36) or a backend (34), wherein, particularly initial coupling, is initiated by an operating unit (30), particularly arranged in the vehicle (10), wherein, at least the authentication message (50, 52, 56) is preferably sent to the authentication tool (12) in encrypted form, and wherein, the authentication message (50, 52, 56) is preferably sent from the authentication tool (12) to the controller (32) in encrypted form.

Description

Background Technology

[0001] The present invention relates to a method for coupling an authentication tool to a vehicle, as described in the preamble of the independent claim.

[0002] A method for operating a remote control device and a remote control device are known from EP 891607B1. In order to teach the control element, if it is determined that a primary control element exists, the base station is used to change the attachment information stored in a storage device. Summary of the Invention

[0003] In contrast, the method according to the invention has the advantage of providing a secure and reliable coupling method between the authentication tool and the vehicle, which can also operate without a data connection between the backend and the vehicle. In particular, the use of timestamps ensures that a time-traceable coupling process initiated by the vehicle also results in actual coupling. Furthermore, encrypted data exchange provides enhanced security. Specifically, decryption of the verification can be performed independently in the vehicle's controller only when appropriate encryption is used. This is achieved according to the invention by the following: the initial coupling is initiated, in particular, by an operating unit specifically arranged in the vehicle, wherein at least the authentication information is preferably transmitted encrypted to the authentication tool, and wherein the authentication information is preferably transmitted encrypted from the authentication tool to the controller.

[0004] In a suitable extension scheme, if the vehicle is not in a data connection with the backend and / or server, the identified data, especially authentication information and / or useful information that triggers coupling, such as timestamps and / or identifiers, particularly the vehicle's identifier, is transmitted to the authentication tool, especially encrypted using the vehicle's and / or the authentication tool's public key. Thus, a reliable data connection is reliably established between the authentication tool and the data required for coupling, precisely during offline operation. On the other hand, additional verification steps are performed, particularly using timestamps, to ensure that the current coupling request is relevant. This further enhances security.

[0005] In a suitable extension scheme, data is transmitted to the authentication tool only after verification by the backend and / or server, specifically verifying whether the current coupled request is involved, for example, by using timestamps and / or comparing timestamps with previously stored timestamps. By centralizing the verification process at the backend or server, coupled requests are processed more efficiently, improving request verification.

[0006] In the extended method that meets the intended purpose, the backend checks whether coupling has been initiated within the vehicle, specifically through the operating unit. This further enhances security because it can now be ensured that sensitive coupling requests are initiated within the vehicle, implying prior authorization of access to the vehicle.

[0007] In a suitable extension scheme, upon initiating coupling, the controller generates or provides useful information, such as timestamps and / or identifiers and / or signatures, particularly through the use of identifiers and / or, especially, the vehicle's private key, and / or data packets composed of timestamps and / or identifiers and / or signatures. Thus, the relevant data becomes available in a particularly secure manner, especially through signing and encryption.

[0008] In a suitable extended solution, data generated or provided by the controller is transmitted to the authentication tool in the vehicle, and / or transmitted via an operating unit and / or a binary code. This ensures that the user must remain in the vehicle, requiring prior access authorization. Furthermore, data transmission occurs on a separate data channel, further enhancing interception reliability.

[0009] In a suitable extended configuration, the server generates at least one authentication message, particularly a password and / or verification and / or additional information, and / or transmits at least one authentication message and / or a timestamp and / or identifier to the backend and / or authentication tool, especially encrypted using the public key of the vehicle and / or the authentication tool. By using the server, information particularly critical to security is reliably generated and forwarded to participating components with high security standards of encryption and / or signature. Thus, a particularly high level of security can be maintained at the central location.

[0010] In a suitable extension scheme, the backend stores at least a portion of the data transmitted by the server, such as authentication information and / or timestamps and / or identifiers, preferably encrypted in a database and / or preferably stored together with unencrypted identifiers. All critical information is aggregated in the backend for subsequent communication with the vehicle identified by the identifier, serving as the component responsible for subsequent communication with the vehicle.

[0011] In a suitable extension scheme, the authentication tool transmits at least one authentication message and / or timestamp and / or identifier to the backend, preferably encrypted using the vehicle's public key. Thus, the backend securely obtains all the critical data required by the coupling program, even when operating offline. However, this information is preferably stored only encrypted within the backend, allowing subsequent decryption within the vehicle to further enhance transmission security.

[0012] In a suitable extension scheme, settings should be configured, particularly through backend verification: whether the timestamps transmitted by the authentication tool are more up-to-date than those stored in the database. This ensures that requests involving the current coupling are considered. This further enhances security.

[0013] In a suitable extension scheme, after successful backend verification, at least one authentication message and / or timestamp and / or identifier, preferably encrypted using the vehicle's public key, is transmitted to the authentication tool. Therefore, sensitive data can only be transmitted if the prescribed coupling procedure is confirmed. This reduces the opportunity for unauthorized individuals to tamper with the data.

[0014] In a suitable extension scheme, especially when the authentication tool is located near the vehicle, at least one piece of authentication information is preferably transmitted from the authentication tool to the controller encrypted via the vehicle's public key, and / or at least one piece of authentication information is stored in the authentication tool. This ensures that data exchange of particularly sensitive information, especially via a different transmission path, is only permitted when the user is near the vehicle. This also reduces the possibility of "unauthorized personnel possessing sensitive data."

[0015] In an appropriate extension scheme, the server and / or authentication tool and / or controller generate authentication from passwords and / or additional information. Security is further enhanced by the chosen authentication method.

[0016] In a suitable extended solution, if the vehicle is not in a data connection with the backend and / or server, specific data, especially authentication information and / or timestamps and / or identifiers, is transmitted from the server to the backend, and / or specific data, especially at least one authentication message, such as a password, is transmitted from the server to the authentication tool, and / or after successful authentication by the backend, specific data, especially regarding the timestamp, especially at least one authentication message, verification and / or auxiliary information, is encrypted and transmitted to the authentication tool, and / or, especially, the authentication tool near the vehicle, transmits specific data, especially at least one verification message, such as verification and / or auxiliary information, especially encrypted, to the controller or vehicle. A particularly secure solution for offline scenarios can be achieved precisely through the combined action of different components and authentication methods, especially encryption, signatures, and verification of useful information.

[0017] In a suitable extension scheme, at least one piece of useful information, particularly a timestamp, is generated based on the coupled request. The determined data, particularly the useful information or timestamp and / or identifier, is transmitted to the authentication tool via an operational unit, whereby data is transmitted from the authentication tool to the server and / or backend. The use of this useful information further reduces the risk of tampering.

[0018] Further extensions that meet the objectives are derived from other preferred embodiments and from the specification. Attached Figure Description

[0019] Embodiments of the present invention will be described in detail with reference to the accompanying drawings. The drawings show:

[0020] Figure 1 A schematic overview diagram showing the components working together;

[0021] Figure 2 A flowchart showing the individual steps of the process. Detailed Implementation

[0022] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0023] Figure 1 A schematic overview of the components working together is shown. Exemplarily, the coupling mechanism of vehicle 10 is described as an example for an enclosed space protected by access authorization. However, this coupling can also be used within the scope of (access) authorization for buildings or other protected spaces or objects.

[0024] Vehicle 10 is capable of communicating with authentication tool 12, such as a smartphone. For this purpose, vehicle 10 includes a controller 32 disposed within vehicle 10. Controller 32 may include at least one communication tool 26 for communicating with authentication tool 12 and / or a backend 34 disposed outside vehicle 10.

[0025] If the authentication tool 12 is coupled to the vehicle 10 or controller 32 in a compliant manner, then the corresponding authentication information 50, 52, 56 is present in these components. As will be explained in more detail below, in this embodiment, a password 50, verification 52, and additional information 56 are used as the authentication information 50, 52, 56. To obtain authorization, such as access authorization or driving authorization for the vehicle 10, the authentication tool 12 and the vehicle 10 or controller 32 exchange the corresponding authentication information 50, 52, 56, and, if they match, allow the corresponding authorization.

[0026] Furthermore, an operating unit 30 is arranged in the vehicle 10. This operating unit may include, for example, a display device, such as a screen, and / or corresponding operating elements. The operating unit 30 can exchange data with the controller 32. For secure data exchange, the public keys of those components that allow communication with the controller 32 are stored in the controller 32. This includes the public key 47 of the server 36 and the public key 60 of the authentication tool 12. For its own encryption or signing purposes, the private key 45 of the vehicle 10 is also stored in the controller 32. Furthermore, the controller 32 further includes an identifier 40, specifically a vehicle identifier 40. Additionally, the controller 32 can generate a timestamp 42. After a successful coupling procedure as described below, verification 52 and additional information 56 are stored in the controller 32.

[0027] A user can access vehicle 10, for example, using an auxiliary authentication tool 14 (keychain, smart card, or similar). Alternatively, access can be authorized via an existing authentication tool 12. For example, a new authentication tool 12, such as another smartphone, or a new owner's authentication tool 12, should be recoupled as described below. The authentication tool 12 stores its private key 61, the server 36's public key 47, and the vehicle 10's public key 58 for secure data exchange purposes. Within vehicle 10 itself, the user can initiate coupling between vehicle 10 and authentication tool 12. This can be done, for example, via operating unit 30. Controller 32 provides specific data, such as a timestamp 42 and a vehicle identifier 44. Furthermore, controller 32 performs a signature or signs the provided data. The signature can be based, for example, on a specific digital signature algorithm, such as ECDSA (Elliptic Curve Digital Signature Algorithm), using the vehicle's private key 45 for this purpose. The corresponding data (timestamp 42, vehicle identifier 40) and signature are encrypted by controller 32, for example, using an encryption algorithm, such as ECIES (Elliptic Curve Synthesis). For encryption, the public key 47 of server 36 (as the intended recipient of the information) is used. The encrypted data or encrypted data container is preferably forwarded to authentication tool 12 via a transmission path within vehicle 10. For example, the transmitted data can be displayed or provided to the transmitter via operating unit 30, for example, in the form of a QR code. The user can scan or read the QR code through authentication tool 12. Upon receiving the read data, the corresponding application on authentication tool 12 automatically invokes the connection with server 36 to transmit the encrypted data or encrypted data container to that server.

[0028] A so-called backend 34 is deployed outside of vehicle 10. Backend 34 can establish data connections with vehicle 10 for different applications during normal operation. For example, a remote backend 34 may be involved. Backend 34 is connected to database 35. Specific data sent to backend 34, such as timestamp 42, identifier 40, especially vehicle identifier (vehicle ID), verification 52, additional information 56, or similar information, can be stored there, preferably assigned to the corresponding vehicle 10. Backend 34 may be operated, for example, by the vehicle manufacturer. Appropriate verifications can be implemented in backend 34. This may involve, for example, verification of timestamp 42 or corresponding verification of signatures or similar verifications.

[0029] In addition, a server 36 is configured, which can establish a data connection with the authentication tool 12 and / or the vehicle 10, preferably via a backend 34. The server 36 may also be located at the vehicle manufacturer. Specific functions important for the data exchange described below can be implemented in the server 36. Therefore, definitive verification can be performed by the server 36, such as verifying the signature 44 and / or timestamp 42. For the purpose of secure data exchange, the server 36 stores, for example, its private key 57, the vehicle 10's public key 58, and the authentication tool 12's public key 60. The server 36 can also generate a password 50. Based on the password 50, a verification 52 and / or additional information 56 can be generated using a specific algorithm, such as the so-called Scrypt algorithm. The data to be transmitted, such as verification 52 and / or additional information 56 and / or password 50, or other information, can be signed, for example, using the server's private key 57 (e.g., by using ECDSA (Elliptic Curve Digital Signature Algorithm)). For example, it can be encrypted using a so-called EC method (elliptic curve cryptography) and / or by using the vehicle's public key 58. For example, the vehicle public key 58 is available to all participants communicating with the vehicle 10, such as the authentication tool 12, the backend 34, and the server 36.

[0030] Encrypted data, such as timestamp 42 and / or preferably unencrypted vehicle identifier 40 and / or verification 52 and / or additional information 56, can be forwarded to backend 34 for storage in database 35 as described. Furthermore, server 36 can encrypt password 50, vehicle identifier 40, and / or digital signature on vehicle identifier 40, preferably using public key 60 (telephone public key) for authentication tool 12. Similarly, public key 60 of authentication tool 12 is known to those participants communicating with authentication tool 12, namely vehicle 10 or controller 32, backend 34, and server 36. Based on password 50, vehicle identifier 40, and the digital signature on password 50, encrypted data packets are sent back within the response to the original call (terminal call) to server 36. If vehicle 10 has established a data connection with backend 34 (vehicle 10 online), vehicle 10 can directly obtain verification 52 and / or additional information 56 from this. However, if vehicle 10 does not establish a data connection with backend 34 (vehicle 10 is offline), authentication tool 12 should receive verification 52 and / or additional information 56 for subsequent forwarding to vehicle 10. However, this is only performed in conjunction with additional checks performed by backend 34.

[0031] To this end, authentication tool 12 forwards the encrypted data obtained from vehicle 10 to backend 34. Backend 34 decrypts the data again and verifies the signature. Next, backend 34 selects encrypted data, verification 52 and / or additional information 56, and timestamp 42 and identifier 40 based on vehicle identifier 40, if the stored timestamp 42 is older than the obtained timestamp 42. If the timestamp 42 now provided is newer than the timestamp 42 stored in database 35 by backend 34, the encrypted data is returned to authentication tool 12, and the new timestamp 42 is stored. If, upon triggering the initial coupling procedure, there is no corresponding information about timestamp 42 in backend 34 or the associated database 35, then the corresponding condition is met and the coupling procedure continues. If, for example, the same timestamp 42 is already present in backend 34 or the associated database 35, then the above condition is not met, and the coupling procedure is interrupted.

[0032] However, authentication tool 12 cannot decrypt the data because it remains encrypted with the vehicle's public key 58. Encrypted data can only be provided to vehicle 10 via a data connection between authentication tool 12 and vehicle 10 when they are close to each other. This can be achieved, for example, via Bluetooth (BLE) or another suitable near-field data connection. Utilizing the information now included, particularly authentication 52, coupling between authentication tool 12 and vehicle 10 can be initiated even when vehicle 10 does not have a direct data connection to backend 34 (vehicle 10 is offline).

[0033] The authentication tool 12 may establish a direct connection with the controller 32 located in the vehicle 10. Alternatively, the connection to the vehicle 10 may be established via a backend 34, which in turn connects to the vehicle 10. Such connections may be made via, for example, Bluetooth, Near Field Communication (NFC), WLAN, Ultra Wideband (UWB), mobile radio, or similar protocols. If the user key of the authentication tool 12 is authorized, access to the vehicle 10 and / or authorization for driving the vehicle 10 are permitted. This is done after a compliant coupling between the authentication tool 12 and the vehicle 10.

[0034] The subsequent authentication method enables authentication even when vehicle 10 is not online and connected to backend 34 or server 36. Therefore, Figure 2 The document describes in detail the exemplary communications between the participating components, namely controller 32, authentication tool 12, backend 34, and server 36.

[0035] After user 11 enters vehicle 10 as described above, the user initiates the coupling function, step 101. This is achieved, for example, by user 11 correspondingly manipulating operating unit 30 and activating the coupling function.

[0036] Operation unit 30 receives the corresponding operation signal from user 11 and generates specific URL parameters, which are then transmitted to controller 32, step 102. This involves relevant information such as how authentication tool 12 can reach the appropriate backend 34 and / or the appropriate server 36, or which backend 34 and / or server 36 it must communicate with within the scope of the coupled request.

[0037] Controller 32 first provides specific data, such as timestamp 42 and identifier 40, particularly vehicle identifier 40. Next, controller 32 generates a signature 44 (or signs the provided data) using a private key 45, particularly the vehicle private key 45, in step 103. Generally, the signature is performed by using the private keys of the specified components. The receiving component uses the public key of the sending component for verification. Furthermore, the information generated in step 103 includes identifier 40, particularly vehicle identifier 40, and / or timestamp 42. Identifier 40, particularly vehicle identifier 40, is a vehicle-specific identifier that clearly identifies vehicle 10. Vehicle identifier 40 is stored in controller 32. Timestamp 42 is, for example, the time when user 11's coupling request is transmitted to operation unit 30 or controller 32. This helps to clearly identify user actions.

[0038] In step 104, the controller 32 encrypts the information generated in step 103 (the signature from step 103, vehicle identifier 40, and timestamp 42). Encryption is performed using the public key 47 of the server 36. Generally, the sending component implements encryption by using the public key of the receiving component. In addition to the data generated in step 103, the subsequent plaintext information, namely identifier 40, especially vehicle identifier 40 and timestamp 42, is also encrypted. At the end of step 104, a so-called encrypted data container is generated as described.

[0039] In the subsequent step 105, the URL parameters and / or, for example, the encrypted data container generated in step 104, are transmitted to the operation unit 30.

[0040] Operation unit 30 creates, for example, the URL parameters transmitted in step 105, step 106. This involves the address of server 36 and the encrypted data generated in step 104, along with the identifier 40 in the plaintext.

[0041] In step 107, the operation unit 30 generates code information for the user 11 from the data generated in step 106. This could, for example, involve a QR code displayed on the screen by the operation unit 30.

[0042] In the next step 108, user 11 verifies the generated code, such as a QR code. To do this, user 11 scans the QR code using authentication tool 12. Thus, user 11 obtains all the information transmitted in step 105 on his authentication tool 12.

[0043] In step 109, authentication tool 12 generates a request to create password 50. In addition to this request, authentication tool 12 also sends the encrypted data container created in step 104 to the corresponding server 36 based on available URL parameters. For this purpose, authentication tool 12 initiates a data connection with server 36.

[0044] In step 110, server 36 decrypts the encrypted data container or transmitted parameters. Decryption is performed using server 36's private key 57.

[0045] In step 111, server 36 verifies the signature of controller 32, which was also transmitted in the encrypted data container. This is done using the vehicle public key 58 created in step 103. If the signature conforms to the specifications, the coupling process continues.

[0046] In step 112, after successful authentication in step 111, server 36 generates password 50. Password 50 is created randomly. Password 50 forms the basis for the subsequent verification 52. Additionally, server 36 generates supplementary information 56.

[0047] In step 113, verification 52 is obtained by server 36. For this, server 36 uses password 50. Furthermore, server 36 uses, for example, additional information 56 generated in step 112. Additional information 56 serves as an input parameter for an algorithm used to create verification 52. This algorithm is, for example, the so-called Scrypt algorithm. This involves a cryptographic key derivation function. Here, random numbers are additionally used in the form of additional information 56, thereby improving the security when creating verification 52.

[0048] In step 114, server 36 generates a signature for password 50 and / or identifier 40 using server 36's private key 57.

[0049] In step 115, the signature created in step 114 is encrypted together with the identifier 40 and password 50 in plaintext form. Encryption is performed using the public key 60 of the authentication tool 12. Therefore, the identifier 40 and password 50 should be available to the authentication tool 12 in subsequent steps.

[0050] In step 116, the additional information 56, verification 52, timestamp 42 and identifier 40, especially vehicle identifier 40, generated in steps 113 and 112 are signed using the private key 57 of server 36.

[0051] In step 117, the information signed in step 116 is encrypted together with other data, such as additional information 56, verification 52, timestamp 42, and identifier 40, especially the vehicle identifier 40, using the public key 58 of vehicle 10. Therefore, in subsequent steps, the additional information 56, verification 52, timestamp 42, and identifier 40 are thus available to vehicle 10 or controller 32.

[0052] In step 118, the encrypted information from step 117 is transmitted from server 36 to backend 34. In addition to the encrypted information, identifier 40 is also transmitted in plaintext.

[0053] Under normal circumstances (with the backend 34 having a data connection to the vehicle 10, i.e., online), communication with a specific vehicle 10 is conducted through the backend 34. The method described here focuses on the case where the vehicle 10 is not connected to the backend 34, i.e., offline.

[0054] In step 119, the backend 34 stores the information transmitted in step 118 in database 35. Therefore, the encrypted information from step 117 and the identifier 40, especially the vehicle identifier 40, are stored in database 35. Here, the identifier 40 is stored in plaintext, while the information from step 117 is encrypted.

[0055] In step 120, the backend 34 confirms with the server 36 that it has received the information transmitted in step 118.

[0056] In step 121, after receiving the response from step 120, server 36 sends the encrypted data packet from step 115 to authentication tool 12. Therefore, identifier 40 and password 50 should be provided to authentication tool 12.

[0057] In step 122, authentication tool 12 uses its private key 61 to decrypt the received data.

[0058] In step 123, authentication tool 12 verifies the signature of server 36, specifically by using the server's public key 47. After successful verification, authentication tool 12 stores password 50 and / or identifier 40. Password 50 is used for subsequent authentication with vehicle 10.

[0059] In step 124, authentication tool 12 transmits the data from step 108 to backend 34.

[0060] In step 125, the backend 34 decrypts the received data using the private key 57 of the backend 34 or the server 36.

[0061] In step 126, the backend 34 verifies the signature of the controller 32 or the vehicle 10 using the public key 58 of the vehicle 10.

[0062] In step 127, backend 34 verifies that a potentially stored timestamp 42 may be older than the timestamp 42 obtained from the encrypted data packet transmission (which becomes usable after decryption). If, upon triggering the initial coupling procedure, there is no corresponding information about timestamp 42 in backend 34 or the corresponding database 35, then the corresponding condition is met and the coupling procedure continues. For example, if the same timestamp 42 is already present in backend 34 or the corresponding database 35, then the above condition is not met, and the coupling procedure is interrupted.

[0063] In step 128, the backend 34 stores the new timestamp 42.

[0064] In step 129, backend 34 transmits the encrypted data container to authentication tool 12. This includes the data container transmitted to backend 34 in step 118.

[0065] However, authentication tool 12 cannot decrypt the encrypted data obtained in step 129 because this data is still encrypted by the public key 58 of vehicle 10. Therefore, only vehicle 10 or controller 32 can decrypt the encrypted data.

[0066] In step 130, if the authentication tool 12 and the vehicle 10 are close together, the authentication tool 12 transmits an encrypted data container (as generated in step 117) to the controller 32 of the vehicle 10. The transmission between the authentication tool 12 and the controller 32 takes place on a separate data channel, which is configured only in the near field. This could involve, for example, a Bluetooth connection (e.g., BLE) or other near-field connections already mentioned.

[0067] Another coupling method can be implemented through controller 32. Specifically, controller 32 decrypts encrypted data using the public key 58 of vehicle 10. In particular, verification 52 and additional information 56 are stored as verification information in controller 32 or vehicle 10 for subsequent verification. By using verification 52, coupling can occur between authentication tool 12 and vehicle 10 or backend 34. Authentication tool 12 is now compliantly coupled to vehicle 10, enabling, for example, access authorization or driving authorization to be achieved through authentication tool 12 and the key.

[0068] For example, authentication is performed by obtaining additional information 56 from the controller 32 via authentication tool 12. Furthermore, authentication tool 12 contains a password 50 (e.g., transmitted in step 121). In authentication tool 12, a verification 52 is formed from the password 50 and the additional information 56 using an algorithm already defined for server 36, for example. The verification 52 formed by authentication tool 12 reaches controller 32, where it is compared with the verification 52 stored in controller 32. If they match, authorization is deduced.

[0069] Alternatively, password 50 can be stored as authentication information in controller 32, while verification 52 and auxiliary information 56 are stored in authentication tool 12. Accordingly, controller 32 can generate verification 52 as described and compare it with the verification 52 stored in verification tool 12. Alternatively, other authentication methods can also be used. Importantly, the corresponding authentication information, as described, arrives at authentication tool 12 and / or controller 32 precisely in the absence of a data connection between vehicle 10 and backend 34 for coupling purposes.

[0070] The coupling procedure described applies to coupling the authentication tool 12 to an object to be authenticated, such as a vehicle 10, an enclosed space, or any other object that can only be used in accordance with regulations by being connected to the associated authentication tool 12. Access authorization or driving authorization is mentioned here only as a representative of a particular mode of use of the object, but its application is not limited thereto.

Claims

1. A method for coupling authentication tools with a vehicle, wherein, The authentication tool (12) communicates with the controller (32) of the vehicle (10) to obtain authorization, wherein once the authentication tool (12) is confirmed to be authorized for the controller (32) by using at least one authentication message (50, 52, 56), at least one coupling is established, wherein for the initial coupling, the authentication message (50, 52, 56) can be generated by a server (36) or a backend (34), wherein the initial coupling is initiated by an operating unit (30) arranged in the vehicle (10), wherein at least the authentication message (50, 52, 56) is encrypted and sent to the authentication tool (12), and wherein the authentication message (50, 52, 56) is encrypted and sent from the authentication tool (12) to the controller (32), wherein the at least one authentication message (50, 52, 56) includes a password (50) and / or verification (52) and / or additional information (56), wherein the additional information includes a password (50) and / or verification (52) and / or additional information (56). Information (56) is used as an input parameter of the algorithm to create the verification (52), wherein if the vehicle (10) is not in a data connection with the backend (34) and / or the server (36), the determined data is transmitted to the authentication tool (12) encrypted and / or signed using the public key of the vehicle (10) and / or the public key of the authentication tool (12), wherein the determined data includes the authentication information (50, 52, 56) and / or useful information that triggers the coupling, wherein the useful information that triggers the coupling includes a timestamp (42) and / or the identifier (40) of the vehicle (10), wherein the data is transmitted to the authentication tool (12) only after verification by the backend (34) and / or the server (36), wherein whether a current coupling request is involved is verified by using the timestamp (42) and / or by comparing the timestamp (42) with a previously stored timestamp (42).

2. The method according to claim 1, characterized in that, The backend (34) checks whether coupling has been initiated in the vehicle (10) by the operation unit (30).

3. The method according to claim 1 or 2, characterized in that, When the coupling is triggered, the controller (32) generates or provides useful information, wherein the useful information includes a timestamp (42) and / or an identifier (40) and / or a signature made by using the identifier (40) and / or the private key (45) of the vehicle (10) and / or a data packet consisting of a timestamp (42) and / or an identifier (40) and / or a signature.

4. The method according to claim 1 or 2, characterized in that, The transmission of data generated or provided by the controller (32) to the authentication tool (12) is carried out in the vehicle (10) and / or by using the operating unit (30) and / or by a QR code.

5. The method according to claim 1 or 2, characterized in that, The server (36) generates at least one authentication information (50, 52, 56) and / or the server (36) transmits at least one authentication information (50, 52, 56) and / or the timestamp (42) and / or the identifier (40) to the backend (34) and / or the authentication tool (12).

6. The method according to claim 1 or 2, characterized in that, The backend (34) stores at least a portion of the data transmitted by the server (36), including the authentication information (50, 52, 56) and / or the timestamp (42) and / or the identifier (40), encrypted in the database (35) and / or together with the unencrypted identifier (40).

7. The method according to claim 1 or 2, characterized in that, The authentication tool (12) transmits at least one authentication information (50, 52, 56) and / or the timestamp (42) and / or the identifier (40) to the backend (34).

8. The method according to claim 1 or 2, characterized in that, The backend (34) verifies whether the timestamp (42) transmitted by the authentication tool (12) is more up-to-date than the timestamp (42) stored in the database (35).

9. The method according to claim 1 or 2, characterized in that, After successful verification by the backend (34), at least one authentication information (50, 52, 56) and / or the timestamp (42) and / or the identifier (40) is transmitted to the authentication tool (12), and / or the transmitted timestamp (42) is stored.

10. The method according to claim 1 or 2, characterized in that, When the authentication tool (12) is adjacent to the vehicle, at least one authentication information (50, 52, 56) is transmitted from the authentication tool (12) to the controller (32), and / or, At least one authentication information (50, 52, 56) is stored in the authentication tool (12).

11. The method according to claim 1 or 2, characterized in that, The server (36) and / or the authentication tool (12) and / or the controller (32) generate the verification (52) from the password (50) and / or the additional information (56).

12. The method according to claim 1 or 2, characterized in that, If the vehicle (10) is not in a data connection with the backend (34) and / or the server (36), the authentication information (50, 52, 56) and / or the timestamp (42) and / or the identifier (40) are transmitted from the server (36) to the backend (34), and / or at least one authentication information (50, 52, 56) is transmitted from the server (36) to the authentication tool (12), and / or after successful verification by the backend (34) in terms of the timestamp (42), at least one authentication information (50, 52, 56) is encrypted and transmitted to the authentication tool (12), and / or the authentication tool (12) encrypts and transmits at least one authentication information (50, 52, 56) to the controller (32) or the vehicle (10) in the near field of the vehicle (10).

13. The method according to claim 1 or 2, characterized in that, At least one piece of useful information is generated according to the coupling request, wherein the at least one piece of useful information includes a timestamp (42), wherein the useful information or timestamp (42) and / or identifier (40) is transmitted to the authentication tool (12) through the operation unit (30), wherein the data is transmitted from the authentication tool (12) to the server (36) and / or the backend (34).

14. The method according to claim 5, characterized in that, The server (36) transmits at least one authentication information (50, 52, 56) and / or the timestamp (42) and / or the identifier (40) to the backend (34) and / or the authentication tool (12) in an encrypted manner and / or signed manner using the public key of the vehicle (10) and / or the public key of the authentication tool (12) and / or using the private key (57) of the server (36).

15. The method according to claim 7, characterized in that, The authentication tool (12) transmits at least one authentication information (50, 52, 56) and / or the timestamp (42) and / or the identifier (40) to the backend (34) in an encrypted manner using the public key (58) of the vehicle (10).

16. The method according to claim 9, characterized in that, After successful verification by the backend (34), at least one authentication information (50, 52, 56) and / or the timestamp (42) and / or the identifier (40) is encrypted and transmitted to the authentication tool (12) via the vehicle public key (58).

17. The method according to claim 10, characterized in that, At least one authentication information (50, 52, 56) is transmitted encrypted from the authentication tool (12) to the controller (32) via the vehicle public key (58) when the authentication tool (12) is in close proximity to the vehicle.

18. The method according to claim 12, characterized in that, The password (50) is transmitted from the server (36) to the authentication tool (12).

19. The method according to claim 12, characterized in that, After successful verification of the timestamp (42) by the backend (34), the verification (52) and / or the additional information (56) are encrypted and transmitted to the authentication tool (12).

20. The method according to claim 12, characterized in that, The authentication tool (12) encrypts the verification (52) and / or the additional information (56) to the controller (32) or the vehicle (10) in the near field of the vehicle (10).

Images