Methods for identifying a user of a service, computer program, device and vehicle
The use of a digital vehicle key with a private key for user identification and secure payment processing addresses the disadvantage of single-factor authentication by enabling efficient and secure payment processing without user interaction.
Patent Information
- Application Number
- DE102023115457
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-06-14
- Publication Date
- 2024-12-19
AI Technical Summary
Single-factor authentication methods require user interaction for payment processing, which is perceived as disadvantageous.
A method using a digital vehicle key assigned with a private key for user identification, enabling secure and efficient payment processing by signing service data with the private key and verifying the digital signature to ensure user identity and integrity.
Facilitates secure and efficient payment processing without direct user interaction, ensuring user identity and integrity through digital signature verification, even in offline conditions.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
[0001] Embodiments of the present invention relate to methods for identifying a user of a service, a computer program, a device and a vehicle, in particular but not exclusively to a concept for determining an identity of a user based on a digital vehicle key.
[0002] Using a service may require payment processing. This payment processing may, for example, be based on one-factor authentication. One-factor authentication is a security procedure that uses a single factor to confirm a user's identity. This factor is typically a password, PIN, or other secret code known to the user.
[0003] With one-factor authentication, the user enters their password or PIN to confirm their identity and access a protected account or system. If the entered password matches the stored password, access is granted. However, one-factor authentication requires user interaction to complete the payment. This can be perceived as a disadvantage by the user.
[0004] There is therefore a need to provide an improved method for identifying a user of a service. The method, device, computer program, and vehicle according to the independent claims address this need.
[0005] Embodiments are based on the core idea that a method for identifying a user of a service can be carried out based on an account identifier (ID) assigned to a digital vehicle key, e.g., an account identifier (ID) assigned to the digital vehicle key. This allows a digital vehicle key of a user terminal to be used to uniquely identify the user. High security standards can apply to a digital vehicle key. For example, a private key of the digital vehicle key is stored in a secure element of the user terminal. This can increase security. Furthermore, the use of the digital vehicle key allows access to an existing infrastructure for user identification.
[0006] Embodiments relate to a method for implementation by a user terminal for identifying a user of a service. The method comprises creating service data indicative of a service requested by the user terminal. Furthermore, the method comprises signing the service data using a private key of a digital vehicle key of the user terminal for identifying a user. The method further comprises sending the signed service data. By signing the service data, a user of the user terminal can ensure the integrity and / or authenticity of the service data. In particular, it can be ensured that a user cannot deny the request for a service. When service data is signed, a digital signature is generated that enables unique identification of the user and ensures that the data has not been altered since it was signed.By using the private key of the digital vehicle key, an account ID can be assigned to the digital vehicle key. This advantageously allows the user of the service to be identified.
[0007] In one embodiment, the service data can be indicative of a payment and a payment ID for the requested service. This allows a unique assignment of the service data to a payment for the requested service.
[0008] Embodiments relate to a method for implementation by a communication device for identifying a user of a service. The method comprises receiving service data indicative of a service requested by a user terminal. The service data can be received by the user terminal. Alternatively, the service data can be received by a relay system. The service data is signed with a private key of a digital vehicle key of the user terminal. Furthermore, the method comprises obtaining a root certificate and verifying the service data based on the root certificate. Optionally, a certificate chain including the root certificate can be obtained. This allows the signature of the digital key and the certificate chain up to the root certificate to be verified. The method further comprises obtaining identification data indicative of an identity of the user of the digital vehicle key.The method further comprises determining an identity of a user of the digital vehicle key based on the checked service data and identification data. By checking with the root certificate, the authenticity of the digital vehicle key can be verified. Furthermore, based on the digital vehicle key, an identity of the user can be determined using the identification data. For example, a digital vehicle key can be linked to a user's account ID. The user's account ID can then be used to uniquely identify the user. In particular, the identity of the user of the digital vehicle key can be determined using the account ID. Optionally, a payment can be processed based on the account ID. For example, the service data can be indicative of a payment and a payment ID for the requested service.This can simplify payment processing.
[0009] In one embodiment, determining the user's identity can include determining account data. The account data can be indicative of an assignment of the digital vehicle key to a user account. The user account can be linked to an account ID and can enable a unique determination of the user's identity. In particular, the digital vehicle key can be uniquely linked to a user's account ID. The linking of the digital vehicle key to a user's account ID can be defined in accordance with the Car Connectivity Consortium (CCC), for example, as defined in Digital Key Release 3.0. This allows access to a CCC infrastructure to determine the user's identity.
[0010] In one embodiment, the method may further comprise accepting a payment confirmation for the service based on the service data and the account data. For example, the service data may be indicative of a payment and a payment ID for the requested service. After determining the user's identity, the communication device may check the service data for the payment and, optionally, the payment ID. If the payment, for example, a payment amount, is sufficient to activate the requested service, the communication device may accept the service data as payment confirmation for the service. For example, the service data may be issued by the communication device as a digital check. The digital check may then be accepted by the user terminal.This allows the communication device to verify a payment for the requested service without requiring a communication connection with a backend.
[0011] In one embodiment, obtaining the root certificate can comprise receiving the root certificate from a backend. Furthermore, obtaining identification data can comprise receiving the identification data from another backend. The method can further comprise storing the root certificate and the identification data. Furthermore, the method can comprise reading the root certificate and the identification data to check the service data and determine the identity of the user. By storing the root certificate and the identification data, the identity of the user can be determined even if the communication device cannot establish a connection to a base station and / or a backend. As a result, a requested service can be enabled for the user terminal even if the communication device lacks connectivity.
[0012] In one embodiment, the method may further comprise storing the service data for later transmission to a payment service provider to verify a payment authenticated by the user terminal. By storing the service data, a requested service can be enabled even if the communication device for the user terminal lacks connectivity.
[0013] Embodiments also provide a computer program for performing one of the methods described herein when the computer program runs on a computer, a processor, or a programmable hardware component.
[0014] Another embodiment is a device for identifying a user of a service. The device comprises an interface for communication with a user terminal or a communication device and a data processing circuit configured to perform at least one of the methods described herein. Embodiments further provide a vehicle with a device as described herein.
[0015] Exemplary embodiments are explained in more detail below with reference to the accompanying figures. They show: Fig. 1 shows a schematic representation of a method for identifying a user of a service; Fig. 2 shows a schematic representation of another method for identifying a user of a service; and Fig. 3 shows a block diagram of an embodiment of a device for identifying a user of a service.
[0016] Various embodiments will now be described in more detail with reference to the accompanying drawings, in which some embodiments are illustrated. In the figures, the thickness dimensions of lines, layers, and / or regions may be exaggerated for clarity.
[0017] Fig. 1 shows a schematic representation of a method 100 for identifying a user of a service. The method 100 includes creating 110 service data indicative of a service requested by the user terminal. The request can be performed using an application installed on the user terminal. For example, the creation 110 can be performed based on user input, for example, user input in an application.
[0018] For example, a user can request a charging session at a charging facility. The service data can therefore be indicative of the charging session request. Optionally or alternatively, other services such as the use of a rental car and / or the payment of a parking ticket can also be requested by the user using the user device. The service can be related to the vehicle with which the digital vehicle key is associated. Optionally or alternatively, the service can be independent of the vehicle with which the digital vehicle key is associated. For example, the service can be a payment in a store, such as a supermarket, a hair salon, or a drugstore, and / or a payment for a public transport ticket. The digital vehicle key can therefore be used in conjunction with the account ID as a general means of payment.For example, the digital vehicle key can be used as a replacement for a credit card. In this case, the payment data used to process a payment can be associated with the account ID of the user of the user device.
[0019] Furthermore, the method 100 comprises signing 120 the service data using a private key of a digital vehicle key of the user terminal to identify a user. The digital vehicle key can in particular be a digital vehicle key within the meaning of the CCC, for example as defined in Digital Key Release 3.0. By signing 120, the integrity and / or authenticity of the service data can be ensured. This can, for example, secure a payment using the service data. The private key of the user terminal can be stored in a security element of the user terminal. A security element can be used to securely store confidential information and to protect against unauthorized access to sensitive data. The security element can be a storage device. The security element can be physically separated from other components of the user terminal.The security element can incorporate strict security measures to protect the integrity of the stored data. This allows for an increased level of security to be achieved through the use of the CCC infrastructure.
[0020] The method 100 further comprises sending 130 the signed service data. The signed service data can be sent 130, for example, to a communication device and / or a relay system. For example, the signed service data can be sent from the user terminal directly to a communication device, for example, a communication device as described with reference to Fig. 2. Alternatively, the signed service data can be sent from the user terminal to a relay system. The signed service data can then be sent, for example, from the relay system to the communications device. The relay system can, for example, be responsible for executing and / or enabling the requested service or simply provide a connection between the user terminal and the communications device.
[0021] In one embodiment, the service data can be indicative of a payment and a payment ID for the requested service. Because the service data can be indicative of a payment (e.g., a payment amount, a payment recipient), a clear assignment to a corresponding payment for the requested service can be provided. Accordingly, the service data can only be used to pay for the requested service. By using a payment ID, it can be ensured that a payment for the requested service is only made once. For example, the service data can function as a digital check. The service data can therefore be used to verify a one-time payment for a requested service. In particular, the service data can be used to initiate this payment at a suitable time.For example, the service data can be stored by a communication device used to activate the service. After storage, the service data can be sent at an appropriate time to a backend, which may be responsible for payment processing. This allows a payment to be verified by the user of the user device. In particular, this allows a user to access the requested service before a payment has been made. The payment can also be made based on the service data after the service has been activated or after the service has been used. This can improve the user experience.
[0022] The user terminal can generally be a device capable of wireless communication. In particular, the user terminal can be a mobile user terminal, e.g., a user terminal suitable for being carried by a user. The user terminal can be, e.g., a user terminal (UT) or user equipment (UE) within the meaning of the respective communication standards used for mobile communication. The user terminal can be, for example, a mobile phone, such as a smartphone, or another type of mobile communication device, such as a smartwatch, a laptop, a tablet computer, autonomous augmented reality glasses, etc.
[0023] Further details and aspects are mentioned in connection with the embodiments described below. Fig. 1 may comprise one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more embodiments described below (e.g. Fig. 2 - 3) were mentioned.
[0024] Fig. 2 shows a schematic representation of another method 200 for identifying a user of a service. The method 200 includes receiving 210 service data indicative of a service requested by a user terminal. The service data can be received from a user terminal and / or a relay system. The service data is signed with a private key of a digital vehicle key of the user terminal. As described with reference to Fig. As described in paragraph 1, the integrity and / or authenticity of the service data can be ensured by signing using the private key of the user terminal.
[0025] Furthermore, the method 200 comprises obtaining 220 a root certificate. The root certificate can be obtained 220, for example, by receiving it from a backend and / or reading it from a storage device. A root certificate is a digital certificate issued by a root CA (Root Certificate Authority). It is the highest certificate in a certificate hierarchy. A root certificate is used to establish trust in the authenticity of certificates and / or certificate chains for secure communication over the Internet. By obtaining 220 the root certificate, the private key or the legitimacy of the digital key and the associated private key of the user terminal can be verified.
[0026] Accordingly, the method 200 further includes checking 230 the service data based on the root certificate. Checking 230 can ensure that the private key is a genuine private key of the digital vehicle key. During the checking, in particular, the certificate chain of the user terminal, which may be contained in the service data, can be checked 230.
[0027] A certificate chain consists of a series of certificates linked together to form the chain of trust from the end certificate to the root certificate. The chain begins with the end certificate, which contains the certificate holder's public key and other identification information. This is followed by intermediate certificates issued by a higher-level CA, which in turn contain its public key. The certificate chain ends with the root certificate.
[0028] The certificate chain enables the trust validation of end certificates. Verification is performed by verifying the signature of each certificate in the chain with the public key of the issuing CA. The received 220 root certificate can therefore be used, in particular, to verify a received certificate chain.
[0029] The method 200 further comprises obtaining 240 identification data indicative of an identity of the user of the digital vehicle key. The identification data can be obtained 240, for example, by receiving it from a backend and / or reading it from a storage device. The identification data can, in particular, be indicative of an account ID of a user of the private key of the user terminal. An identity of the user can be associated with the account ID. For example, authentication of the user, for example by means of an identity card or a passport, can be required to create the account ID. Accordingly, the account ID can be uniquely assigned to a user. For example, the account ID can replace verification by an identity card or a passport.
[0030] Furthermore, the method 200 includes determining 250 an identity of a user of the digital vehicle key based on the verified service data and identification data. By determining 250 the identity of the user, the requested service can be enabled for the user. The identity of the user is determined 250 based on the verified service data and identification data.
[0031] The verified service data is particularly indicative of the private key of the user device's digital vehicle key, which was used to sign the service data. The private key of the digital vehicle key can then be used, based on the identification data, to identify the service user. For example, the digital vehicle key can be linked to an account ID. By using the digital vehicle key with the account ID, a user can be uniquely assigned to the user device's private key. This makes it easier to identify the service user.
[0032] In addition to being used as a vehicle key, the digital vehicle key can also serve as the user's digital identity. The digital vehicle key can provide a unique, particularly cryptographically confirmed, association with a user device. The so-called account ID according to the CCC specification can be used for this purpose. The account ID can be used to establish an association with the user's user account on the respective user device platform. This association (digital vehicle key to account ID) can be used to uniquely identify the user. Optionally, payments can be initiated to this account ID based on the unique identification.The actual authorization by the user can be performed by cryptographically signing a payment request, which is included in the service data, using the private key of the digital key pair. For this purpose, the certificate, especially the root certificate, can be included. The certificate can contain the associated account ID in metadata; see also the CCC specification.
[0033] Optionally, the method 200 can also be used for two-factor authentication (2FA). 2FA is a security method that uses two different types of information to confirm a user's identity. This increases security over traditional one-factor authentication methods that only require a password or PIN. Typically, 2FA involves a piece of information the user knows, such as a password or PIN, and something the user possesses, such as a mobile phone, special hardware such as a security token, or a smart card.
[0034] When logging in or accessing a protected account, the user is first asked for their username and password. A password request could, for example, be performed by an application requesting the service. A second authentication method can then be performed, such as a one-time PIN sent via SMS to the user's mobile phone or signing the service data using the private key of the digital vehicle key. The signed service data can therefore be used to prove the user's ownership of the user device.
[0035] In one embodiment, determining the user's identity may include determining account data. The account data may be indicative of an assignment of the digital vehicle key to a user account. The user account may be associated with an account ID. An account ID may be defined as a unique identifier or number that can be assigned to a specific user account. It can often be used in various online platforms, services, or systems to identify users and manage their accounts. Each account can typically be assigned a unique account ID to ensure a clear distinction between different accounts.
[0036] The management of the account ID is usually the responsibility of the platform or service where the account is created. This could be, for example, a social network, an online store, an email service, an online game, or a manufacturer of the user's device. The platform or service assigns a unique account ID to the user account and manages it internally. The user generally has limited options for managing or changing the account ID themselves. Using the account ID makes it easier to assign a user account.
[0037] In one embodiment, method 200 may further include accepting a payment confirmation for the service based on the service data and the account data. For example, the service data may be indicative of a payment and a payment ID for the requested service. The signed service data may, in particular, function as a digital check. The communication device may initiate payment processing based on the signed service data. The service data does not need to be sent directly to a payment processing entity for payment processing. For example, the communication device may perform a transmission at a suitable time, such as a time with low data traffic.
[0038] In particular, the signed service data can include a payment confirmation. The payment confirmation can then be accepted by the communication device, in particular without having to establish a communication connection with a payment service provider. This allows the communication device to activate a service without requiring a pre-processed payment. This can improve the user experience.
[0039] In one embodiment, obtaining the root certificate can comprise receiving the root certificate from a backend. Furthermore, obtaining identification data can comprise receiving the identification data from a further backend. The further backend can be identical to or different from the backend. The method 200 can further comprise storing the root certificate and the identification data. Furthermore, the method 200 can comprise reading the root certificate and the identification data to check the service data and determine the identity of the user. By storing the root certificate and the identification data, the identity of the user can be determined even if the communication device cannot establish a connection to a base station and / or a backend. As a result, a requested service can be enabled for the user terminal even if the communication device lacks connectivity.
[0040] In one embodiment, the method may further comprise storing the service data for later transmission to a payment service provider to verify a payment authenticated by the user terminal. By storing the service data, a requested service can be enabled even if the communication device for the user terminal lacks connectivity.
[0041] Optionally or alternatively to payment processing, the method 200 according to the invention can also be used to activate a requested service. For example, a service can be activated for a user. By identifying the user, the communication device can determine whether the service is activated for the user. This can simplify the activation of the service for the user.
[0042] The communication device can generally be a device capable of wireless communication. The communication device can communicate with a backend, e.g., a base station, in a mobile communication system. For example, the communication device can communicate within / via a mobile communication system. The mobile communication system can include a plurality of transmission points and / or base stations capable of transmitting radio signals with the communication device.
[0043] Further details and aspects are mentioned in connection with the embodiments described below and / or above. Fig. 2 may comprise one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more of the above (e.g. Fig. 1) and / or embodiments described below (e.g. Fig. 3) were mentioned.
[0044] Fig. Figure 3 shows a block diagram of an embodiment of a device 30 for identifying a user of a service. The device 30 comprises an interface 32 for communication with a user terminal (for example, the user terminal which is described with reference to Fig. 1) or a communication device (for example, the communication device described with reference to Fig. 2). The device 30 further comprises a data processing circuit 34 which is designed to carry out at least one of the methods described herein, for example the method which is described with reference to Fig. 1 for the user terminal or with reference to Fig. 2 for the communication device. Further embodiments include a vehicle 40 with a device 30.
[0045] The Fig. The interface 32 shown in Figure 3 can, for example, correspond to one or more inputs and / or one or more outputs for receiving and / or transmitting information, for example in digital bit values, based on a code, within a module, between modules, or between modules of different entities. The interface 32 can, for example, be configured to communicate with other network components via a (radio) network or a local area network.
[0046] In exemplary embodiments, the data processing circuit 34 can correspond to any controller or processor or a programmable hardware component. For example, the data processing circuit 34 can also be implemented as software programmed for a corresponding hardware component. In this respect, the data processing circuit 34 can be implemented as programmable hardware with appropriately adapted software. Any processors, such as digital signal processors (DSPs), can be used. Exemplary embodiments are not limited to a specific type of processor. Any processor or even multiple processors are conceivable for implementing the data processing circuit 34.
[0047] As in Fig. 3, the interface 32 may be coupled to the respective data processing circuitry 34 of the device 30. In examples, the device 30 may be implemented by one or more processing units, one or more processing devices, any means of processing, such as a processor, a computer, or a programmable hardware component operable with appropriately adapted software. Likewise, the described functions of the data processing circuitry 34 may also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may be a general-purpose processor, a digital signal processor (DSP), a microcontroller, etc.The data processing circuit 34 may be capable of controlling the interface 32 such that any data transfer that occurs over the interface 32 and / or any interaction that the interface 32 may be involved in can be controlled by the data processing circuit 34.
[0048] In one embodiment, the device 30 may include a memory and at least one data processing circuit 34 operatively coupled to the memory and configured to perform one of the methods described above.
[0049] In examples, interface 32 may correspond to any means for obtaining, receiving, transmitting, or providing analog or digital signals or information, e.g., any terminal, contact, pin, register, input terminal, output terminal, conductor, trace, etc., that enables the provision or receipt of a signal or information. Interface 32 may be wireless or wired and may be configured to communicate with other internal or external components, e.g., to send or receive signals or information.
[0050] In at least some embodiments, the vehicle 40 may, for example, correspond to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, a bus, a motorcycle, an off-road vehicle, a motor vehicle, or a truck. The device 30 may, for example, be a part of or a control unit of the vehicle 40.
[0051] Further details and aspects are mentioned in connection with the embodiments described above. Fig. 3 may comprise one or more optional additional features corresponding to one or more aspects related to the proposed concept or one or more of the above (e.g. Fig. 1 - 3) described embodiments were mentioned.
[0052] Further embodiments are computer programs for carrying out one of the methods described herein when the computer program runs on a computer, a processor, or a programmable hardware component. Depending on specific implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be carried out using a digital storage medium, for example a floppy disk, a DVD, a Blu-ray disc, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, a hard disk, or another magnetic or optical storage device on which electronically readable control signals are stored that can interact or interact with a programmable hardware component in such a way that the respective method is carried out.
[0053] A programmable hardware component can be formed by a processor, a computer processor (CPU = Central Processing Unit), a graphics processor (GPU = Graphics Processing Unit), a computer, a computer system, an application-specific integrated circuit (ASIC = Application-Specific Integrated Circuit), an integrated circuit (IC = Integrated Circuit), a single-chip system (SOC = System on Chip), a programmable logic element or a field-programmable gate array with a microprocessor (FPGA = Field Programmable Gate Array).
[0054] The digital storage medium can therefore be machine- or computer-readable. Some embodiments thus comprise a data carrier having electronically readable control signals capable of interacting with a programmable computer system or a programmable hardware component such that one of the methods described herein is performed. One embodiment is thus a data carrier (or a digital storage medium or a computer-readable medium) on which the program for performing one of the methods described herein is recorded.
[0055] In general, embodiments of the present invention can be implemented as a program, firmware, computer program, or computer program product with program code or data, wherein the program code or data is effective to perform one of the methods when the program runs on a processor or a programmable hardware component. The program code or data can also be stored, for example, on a machine-readable medium or data carrier. The program code or data can be present, among other things, as source code, machine code, or bytecode, as well as other intermediate code.
[0056] The above-described embodiments are merely illustrative of the principles of the present invention. It is understood that modifications and variations of the arrangements and details described herein will be apparent to others skilled in the art. Therefore, it is intended that the invention be limited only by the scope of the following claims and not by the specific details presented in the description and explanation of the embodiments herein. List of reference symbols 30 Device 32 interface 34 Data processing circuit 40 vehicles 100 methods for identifying a user of a service 110 Creating service data 120 Signing the service data 130 Sending the signed service data 200 Procedures for identifying a user of a service 210 Receiving service data 220 Obtaining a Root Certificate 230 Checking the service data 240 Obtaining identification data 250 Determining a user's identity
Claims
[1] A method (100) for performing by a user terminal for identifying a user of a service, comprising Creating (110) service data indicative of a service requested by the user terminal; Signing (120) the service data using a private key of a digital vehicle key of the user terminal to identify a user; and Sending (130) the signed service data. [2] The method (100) of claim 1, wherein the service data is indicative of a payment and a payment identifier for the requested service. [3] A method (200) for performing by a communication device for identifying a user of a service; Receiving (210) service data indicative of a service requested by the user terminal, the service data being signed with a private key of a digital vehicle key of the user terminal; Obtaining (220) a root certificate; Checking (230) the service data based on the root certificate, Obtaining (240) identification data indicative of an identity of the user of the digital vehicle key; and Determining (250) an identity of a user of the digital vehicle key based on the verified service data and the identification data. [4] The method (200) of claim 3, wherein determining the identity of the user comprises determining account data, the account data indicative of an assignment of the digital vehicle key to a user account. [5] The method (200) of any one of claims 3 or 4, further comprising accepting a payment confirmation for the service based on the service data and the account data. [6] The method (200) according to any one of claims 3-5, wherein obtaining the root certificate includes receiving the root certificate from a backend; obtaining identification data comprises receiving the identification data from another backend; and the method further comprises Storing the root certificate and identification data; and Reading the root certificate and identification data to verify the service data and determine the user's identity. [7] The method (200) of any of claims 3-6, further comprising storing the service data for later transmission to a payment service provider for substantiating a payment authenticated by the user terminal. [8] A computer program for carrying out one of the methods (100; 200) according to one of the preceding claims, when the computer program runs on a computer, a processor, or a programmable hardware component. [9] A device (30) for identifying a user of a service, comprising: an interface (32) for communication with a user terminal or a communication device; and a data processing circuit (34) configured to carry out at least one of the methods (100; 200) according to any one of claims 1-7. [10] A vehicle (40) having a device (30) according to claim 9.
Citation Information
Patent Citations
car keys, communication system and procedures for this
DE102015114209A1
Method for authorizing a first participant in a communications network, processing equipment, motor vehicle and infrastructure equipment
DE102021106261A1
Chain of authentication using public key infrastructure
US20220116231A1
Cited By
Procedure for the secure establishment of a public cryptographic key on a communication partner for secure communication, and communication order for carrying out the procedure.
DE102025101355A1
