Techniques for signing data with digital vehicle key

Abstract

A method for signing data with a digital vehicle key (112) comprises: receiving an indication (124) of a selected signature mode, where the signature mode is selected from at least one first signature mode (128, 132) involving a signature with participation of a user (108) and a second signature mode (136) involving a signature with participation of the user (108), where the at least one first signature mode (128, 132) involving a signature with participation of the user (108) and the at least one second signature mode (136) involving a signature with participation of the user (108); and the second signature pattern (136) relates to a signature without participation of the user (108); signing the data according to the selected signature mode (126); sending (140) the signed data; and receiving feedback (148) regarding the signed data.

Description

Technical Field

[0001] This invention relates to a technique for signing data using a digital vehicle key. The technique is specified for implementation in mobile devices and in vehicle-mounted backend systems. Background Technology

[0002] Motor vehicles can be secure using a scheme defined by the Connected Car Alliance (CCC) as "Digital Key." A full description appears, for example, in the technical specification "Digital Key Release 4." This scheme specifies that security functions of the motor vehicle, such as central locking systems and / or anti-theft locks, are controlled based on asymmetric encryption methods. Users can configure a digital vehicle key in the form of an encrypted data structure. Wireless connectivity is used between the mobile device and the motor vehicle for authentication based on this key.

[0003] A digital vehicle key may include, for example, a private and a public portion. The private portion can be stored in a secure environment on a mobile device. Conversely, a digital key is equipped on a motor vehicle, with its private portion stored in the onboard control system. The public portion is known to the user. To control security or access functions, authentication is performed between the two parties based on the respective private and public key portions. If authentication is successful, then the required security functions on the motor vehicle can be controlled, enabling access to or use of the vehicle, etc.

[0004] Digital signatures can be created using digital vehicle keys conforming to CCC specifications. Such digital signatures can, for example, be specified in message exchanges. An example is a so-called standard transaction, as defined by the CCC, used to establish secure transmission channels, which includes corresponding checks or verifications by the counterparty. Another example involves applications for handling digital vehicle keys on mobile devices; such applications should be able to proactively create signatures for different data.

[0005] To create such a signature, the CCC standard mandates user consent, while user authentication is optional. Obtaining consent requires at least one pop-up on the mobile device, and authentication involves a more complex process. Such measures prolong and complicate the upper-level process. However, it is inappropriate to burden the user with such a laborious process, depending on which data should be signed. For a small amount of security-critical data, it would be natural to simply omit the creation of a verified signature altogether, but this is not a satisfactory solution from a security perspective. Summary of the Invention

[0006] One of the objectives of this invention is to provide an improved solution for the technology of signature creation and verification based on digital vehicle keys. This objective is achieved by means of the independent claims. The dependent claims describe preferred embodiments.

[0007] A first aspect of the invention relates to a method for signing data using a digital vehicle key. The method can be implemented at the user's end, for example on a person's mobile device—on which the digital vehicle key is stored—and preferably on the mobile device in an application for processing the digital vehicle key. The method includes receiving an instruction for a selected signature mode. The signature mode is selected from at least one first signature mode and a second signature mode. At least one first signature mode relates to signing with user participation. The second signature mode relates to signing without user participation. The method further includes: initiating the signing of data according to the selected signature mode; sending the signed data; and receiving feedback regarding the signed data, i.e., for example, regarding an inspection of the signed data.

[0008] A second aspect of the invention relates to a method for inspecting data signed using a digital vehicle key. This method can be implemented, for example, in a vehicle-side backend system. The method includes sending an indication of a selected signature mode. The signature mode is selected from at least one first signature mode and a second signature mode. The at least one first signature mode relates to signing with user participation. The second signature mode relates to signing without user participation. The method further includes: receiving signed data; inspecting the received signed data; and sending feedback based on the inspection of the signed data, i.e., feedback regarding an action or operation performed based on the inspected data.

[0009] In some embodiments of the invention, at least one first signature mode includes a signature mode involving user consent or approval and / or a signature mode involving user verification or authentication. To obtain user consent, for example, a pop-up window may be displayed on the mobile device's screen, and the user may grant consent by tapping or clicking to make the pop-up window disappear. Authentication may be implemented, for example, using a fingerprint sensor, facial recognition, password input, etc. Obtaining user consent and / or authentication becomes expensive for the user, delays other processes, and generally reduces user comfort. According to the invention, obtaining consent or authentication is omitted for certain data, but signature creation is not omitted. The second signature mode proposed according to the invention is sufficient without user involvement and therefore enables more comfortable and faster verification.

[0010] Embodiments of the invention provide multiple signature modes, at least one of which is sufficient in the absence of user involvement. In one embodiment, "no involvement" means a signature mode in which a signature is created without user consent and without user authentication (as would be required in other signature modes). Such a signature mode may be specified, for example, if the data or the action associated with the data is not highly security-related, thus on the one hand, implementing a cumbersome and time-consuming consent and / or authentication process for the user is inappropriate, but on the other hand, a security process should not be omitted. In one embodiment, the signature mode according to the invention thus complements two signature modes involving user consent or authentication, providing another (third) particular combination or balance between security and user comfort.

[0011] In the defined embodiments of the invention, successful authentication of the created signature is a prerequisite for actions, operations, functionalities, processes, techniques, activities, measures, etc., implemented, for example, in a backend system. Some embodiments may involve, for example, the creation of signatures for simple or unilaterally directed data streams (as opposed to message exchange, handshakes, etc.) and data stream-based actions, such as, for example, the configuration of user accounts (based on corresponding user identification) and digital vehicle keys.

[0012] In some embodiments of the invention, the method according to the first aspect of the invention further includes: passing a selected signature pattern to a secure element; and having the secure element receive data signed according to the selected signature pattern. This makes the creation of the signature particularly secure.

[0013] In some implementations, the data to be signed is also passed to the secure element. The secure element signs the passed data with a digital vehicle key stored in the secure element and, for example, with a predetermined data structure having multiple data fields.

[0014] In some implementations, the chosen signature mode is the second signature mode, and the secure element performs the signature without user intervention. For example, each output can be stopped on the user interface, or at least each output requiring user intervention, such as pop-ups or windows instructing on authentication, can be stopped. Thus, the application of the second signature mode increases user comfort while simultaneously generating signatures securely.

[0015] In a preferred embodiment of the first aspect of the invention, the signature is implemented imperceptibly to the user without user participation, that is, the process is implemented in the background from the user's perspective, while another process is implemented in the foreground, such as the connection between the mobile device and the motor vehicle by means of the digital vehicle key stored in the mobile device, key sharing or key forwarding, etc., or the other process is not implemented in the foreground, that is, the mobile device appears inactive, passive, or in a waiting state, etc.

[0016] In some implementations, the transmission of the instruction for the selected signature mode includes an information field, that is, at least two different predetermined values ​​for the instruction of the corresponding signature mode. For example, at least one specific value may be provided for the instruction of a first signature mode (with user participation), and different specific values ​​may be specified for the instruction of a second signature mode (without user participation).

[0017] The information field may, for example, involve a data field of the SIGN command according to the specifications of the Connected Cars Consortium (CCC). The data field may involve, for example, a tag 93h (or 0x93, i.e., written in hexadecimal), which has a length and a description or value, each describing a defined signature pattern (at least one of the first and second signature patterns).

[0018] In some embodiments of the second aspect of the invention, the backend system determines the signature mode to be applied. This can, for example, mandate user authentication for specific service requirements. In other embodiments, the mobile device or an app on the mobile device can autonomously determine the signature mode. In some of these embodiments, the method further includes: receiving a request concerning a signature; checking the received request; and selecting a signature mode from at least one first signature mode and a second signature mode based on the check. These embodiments provide flexibility in determining the signature mode to be applied.

[0019] In some embodiments of the second aspect of the invention, the inspection of the received signed data includes an inspection based on the digital vehicle key signature. For example, the public key portion of the digital vehicle key may be present in the backend system, thereby enabling the inspection.

[0020] In some of these or other implementations, the inspection of received signed data may involve the inspection of user input or other user processing involving actions, operations, etc. The user input or processing does not necessarily directly involve the performed action. Thus, for example, the storage of a digital vehicle key in a mobile device triggered by the user could be a trigger mechanism for configuring a user account and the assigned digital vehicle key in the vehicle's backend system.

[0021] In certain embodiments, the method according to the second aspect of the invention may include performing actions, operations, etc., after a successful check. Feedback based on the check of the signed data may include feedback relating to the (e.g., successful) implementation of an action. Feedback may include output via a user interface of a mobile device, such as instructions to perform an action, which, however, does not require a user response. In other embodiments, such output is omitted, i.e., the signing process and / or the implemented actions occur entirely in the background.

[0022] Another aspect of the invention relates to a mobile device configured to sign data using a digital vehicle key according to the method described herein. "Mobile device" should be understood herein as a tablet computer, smartphone, smartwatch, smart bracelet, smart ring, etc., and generally, however, as each such device on which a digital vehicle key, an assigned vehicle key (in the case of "key sharing"), etc., can be stored, and which can be used to access a motor vehicle. This could also be the case of a mobile device with a smart card, or any other case or future device, having the necessary processor capabilities, storage capacity, etc.

[0023] In one embodiment, the mobile device may include a secure environment and / or a secure element for storing digital vehicle keys. In some embodiments, the secure environment or secure element may be provided, for example, by means of a cryptographic processor. In some specific embodiments, the secure environment or secure element may refer to, for example, an HSM (“Hardware Security Module”), a TPM (“Trusted Platform Module”), a “Secure Zone”, a TEE (“Trusted Execution Environment”), and / or a secure element in the sense of a “secure element”. Such a secure environment may store, for example, electronic, encrypted, or digital vehicle keys, derived vehicle keys, certificates, etc.

[0024] Software, applications (“Apps”), etc., can be installed on mobile devices to implement device-side control of the signing process, including, where necessary, interaction with secure elements. For example, an App might be provided by the vehicle manufacturer for processing digital vehicle keys related to the motor vehicle.

[0025] Another aspect of the invention relates to a server, for example, in a backend system for a vehicle, configured to examine data signed with a digital vehicle key according to one of the methods described herein. The server may also involve multiple servers, server architectures, etc. One or more servers may be operated, for example, by the vehicle manufacturer. Software for the server, for example, for operable and / or manageable key management, can implement the method according to the invention.

[0026] Another aspect of the invention relates to a system comprising a motor vehicle configured to store a digital vehicle key. The system further includes a mobile device configured to sign data using the digital vehicle key according to the methods described herein. The system also includes a backend server configured to examine the data signed using the digital vehicle key according to the methods described herein. Attached Figure Description

[0027] The invention will now be described more precisely with reference to the accompanying drawings, in which it is clarified that:

[0028] Figure 1 :system;

[0029] Figure 2A : Flowchart of the first method;

[0030] Figure 2B : The flowchart of the second method; and

[0031] Figure 3 : Flowchart of the third method. Detailed Implementation

[0032] Figure 1 The system 100 is schematically shown, including a motor vehicle 102, a server 104 in a back-end system for the vehicle 102, and a mobile device 106 for a user 108.

[0033] The reference numeral "104" is used in the following text not only to generally refer to one or the backend system 104 (especially for vehicle 102) but also specifically to refer to server 104, which may also involve multiple interconnected servers.

[0034] The mobile device 106 has a secure element 110, which may involve a "secure area", a TEE, etc. Generally speaking, the secure element 110 may be provided, for example, by an encryption processor.

[0035] A digital vehicle key 112 for vehicle 102 is stored in secure element 110. More precisely, an endpoint (according to the CCC data structure) exists in secure element 110 representing the digital vehicle key 112 on mobile device 106. A corresponding endpoint exists in vehicle 102, representing the digital vehicle key 112 in the same form as stored in vehicle 102. The details of the representation of the digital vehicle key 112, both in mobile device 106 and vehicle 102, are readily understood by those skilled in the art and will therefore not be described further.

[0036] It should be noted that the communication between the mobile device 106 and the backend system 104, as described below, may be based on one or more connections on a mobile radio basis and / or on a short-range wireless connection, wherein, for example, the vehicle 102 may be used as a relay station for forwarding communication between the mobile device 106 and the backend server 104. This will not be discussed further in the subsequent description for clarity.

[0037] The CCC standard specifies that digital signatures (“digital signature” is sometimes simply abbreviated as “signature”) can be created using a digital vehicle key. The creation and verification of signatures can be specified in unilateral or bilateral message exchanges. For example, it can be specified that an application or App used to process the digital vehicle key 112 on mobile device 106 creates a signature for arbitrary data.

[0038] The CCC specification provides a "SIGN" command for this purpose. More precisely, the data field of the SIGN command is specified to indicate whether user authentication is required for signature creation, or whether such authentication is implemented, see Usage-Tag ("Usage-Tag") 93h or 0x93.

[0039] More precisely, the creation of a proof for the verification of any data (“Data Attestation”) can be mandated to have the consent or approval of user 108, while the authentication of user 108 is optional.

[0040] If the signature creation is based on user 108's consent, then a pop-up window should be displayed to user 108 informing them that digital vehicle key 112 is used to create the signature. The use of the aforementioned label would indicate that user authentication is not implemented.

[0041] If user authentication is implemented, where explicit authentication of user 108 is required, such as PIN (“Personal Identification Number”), password input, facial recognition implementation, etc., then label 93h indicates that user authentication has been implemented.

[0042] If only these two signature modes are available, then any implementation of data signature creation always requires at least a pop-up window to be displayed on mobile device 106 and corresponding user intervention (i.e., the corresponding participation of user 108). This type of signature creation may be inappropriate for user 108 in certain situations, such as if it interrupts, prolongs, and / or complicates other interactions between user 108 and mobile device 106. This could be, for example, during the implementation of complex processes, such as the storage of the digital vehicle key 112 for vehicle 102 in mobile device 106, or key sharing or key forwarding, etc.

[0043] In this scenario, the solution completely eliminates the need for signature creation (and verification). This naturally compromises security, meaning the security solution will be flawed.

[0044] The present invention proposes, instead, a third mode to supplement and extend the above-mentioned scheme with two modes, "user consent" and "user authentication". This mode may be called "silent" or "silence", or background mode, because it operates without user consent and without user authentication, which is required in the two other modes: in background mode, a signature is created in the background from the user's perspective, that is, without user intervention as required in the other modes, and is imperceptible to the user, that is, there is no output on the user interface of mobile device 106 (or at least no output that user 108 must respond to).

[0045] The proposed signature pattern enables signature creation for applications with low security risks, while maintaining the following level of security, where the digital vehicle key 112 securely stored on the mobile device 106 is used for signature creation, meaning that signature creation (and verification) does not have to be completely omitted.

[0046] A typical application scenario—which may require user authentication—could be, for example, the purchase of expensive items for user 108's private car 102 within an app on mobile device 106 (if the app is configured to handle digital vehicle key 112). A typical application scenario—which may require user 108's consent—could be, for example, a request for key forwarding for key 112.

[0047] A typical application scenario—which could involve "background" signature creation as proposed in this invention, i.e., without user involvement—could be, for example, the association or configuration of user 108's vehicle or device account ID with digital vehicle key 112. Such configuration can run in backend system 104 and can be triggered by other processes, such as creating a new user account or storing digital vehicle key 112 on mobile device 106.

[0048] In one embodiment of the security scheme, another application scenario for creating a signature in the background according to the present invention may involve data that is not transmitted during the exchange of messages between the two parties, but rather in a unilateral message stream, such as data transmitted to the backend system of the vehicle or device. Other security schemes, however, are also possible.

[0049] Backend server 104 may require two or three (or more) defined signature patterns. Depending on the application's security criticality and potential for damage, server 104 may require, for example, a signature pattern running in the background, a signature pattern with user consent, or even a signature pattern pre-defined with user authentication. The pre-defined signature pattern used for creation is considered when verifying the created signature in backend system 104 (or in another instance). This prevents compromised apps on mobile device 106 from independently creating signatures and thereby compromising the security scheme.

[0050] In CCC-based embodiments, the tag (93h) used for implementing the SIGN command in the backend system must be representative of all signature patterns. If the tag contains, for example, the value (4 bytes long) D074DA4Fh, then this could be a description of a signature pattern involving user authentication; and if the tag contains the value FC6F4C17h, then this could be a description of a signature pattern involving user consent. For signature patterns used for backend signing according to the present invention (e.g., the third), a predetermined value XXXXXXXXh should be configured accordingly, where each "X" can individually take a value between 0…F.

[0051] In the illustrated embodiment and referring back to Figure 1 In process 120 (which may include one or more user inputs), user 108 interacts with mobile device 106, for example, to implement a connection (“owner pairing”), where a digital vehicle key 112 for vehicle 102 is stored in mobile device 106. After process 120 successfully completes, user 108's account ID should be associated with the digital vehicle key 112 in backend system 104 (as stored in backend system 104). This additional process 122 has minor security implications but should not be operated entirely insecurely. Signature creation with user intervention would, however, be inappropriate and confusing and disruptive to user 108.

[0052] Therefore, process 122 includes signature creation without user intervention, as described below. First, the App on mobile device 106 requests a signature creation pattern from backend system 104 in request 124, and obtains a predetermined signature pattern from backend system 104, for example, based on a predetermined security scheme, wherein specific security requirements are defined for specific data. In process 126, secure element 110 creates a signature based on a digital vehicle key 112 stored therein, according to the predetermined signature pattern.

[0053] More precisely, the backend system 104 can selectively predefine one of three signature modes, and the secure element 110 implements this predefinement. Signature mode 128 requires the consent of user 108, for example, by clicking a pop-up window on the display of mobile device 106. A corresponding instruction 130 of user 108's participation (e.g., in the form of a tag or similar tag as described above) reaches mobile device 106, more specifically, secure element 110, and secure element 110 creates a signature only if instruction 126 is present. Signature mode 132 requires authentication of user 108, for example, by applying the fingerprint sensor of mobile device 106. Element 110 creates a signature only if the instruction or proof of user 108's implemented participation (authentication) reaches secure element 110.

[0054] (Third, additional, and final) Signature pattern 136 does not require user 108's participation as in patterns 128 and 132. If signature pattern 136 is pre-defined, the secure element creates the required signature based on the transmitted data and digital vehicle key 112, without waiting for user participation instructions (such as instructions 130 or 134), because no such instructions exist, as in... Figure 1 As indicated in the figure, see reference numeral 138. Instead, the signing process 122 (if based on signing mode 136) runs in the background, meaning it is not involved and is imperceptible to user 108.

[0055] In a further step of process 122, mobile device 106 (or the executing App) sends the signed data to backend system 104 in transmission 140. If necessary, signature creation is checked in process 142, i.e., it is determined which signature mode is pre-defined, and for signature mode 128 or 132, it is checked whether the corresponding participation of user 108 is achieved on device 106. Such a check is cancelled for signature mode 136 because participation is not required.

[0056] In process 144, the signature created by security element 110 is checked. If the check is successful, the required action is performed in process 146, such as assigning an account ID to digital vehicle key 112. In process 148, the execution of the action is confirmed, thereby implicitly confirming the successful check of the signature and the signed data.

[0057] Instead of Figure 1The signature patterns 128 and 132 shown can also have additional signature patterns involving user 108. For example, multiple signature patterns involving user authentication can each require a fully defined form of authentication, such as facial recognition, password input, etc. Alternatively, there can be only one signature pattern that requires user intervention, such as a response to a pop-up window, so that only two signature patterns are available in total: one with user involvement and one without.

[0058] Although instructions 130, 134, or 138 are for simplified understanding Figure 1 The instructions 130, 134, and 138 are shown in association with user intervention 128 and 132 or no user intervention 138, but it will be clear to those skilled in the art that these instructions 130, 134, and 138 can be expressed as different values ​​of the tag used in the SIGN command, wherein the backend system 104 may optionally predefine one of these values ​​for signature creation.

[0059] Specific embodiments of the cooperation between mobile device 106 and backend system 104 according to the present invention for signature creation are referred to below. Figure 2A and 2B The process illustrated in the diagram is described more accurately. Figure 2A The process of method 200 in mobile device 106 is shown. Figure 2B The flow of method 250 in the backend system 104 is shown.

[0060] The process is described in Method 200 in Appendix Figure 2A The process begins with pre-processing step 202, where input from user 108 is received. This can be, for example, as described above for... Figure 1 The process occurs as described in step 120. In step 204, the mobile device 106 sends a signature mode request to the backend system 104. Figure 2B In step 252 of method 250, the backend system 104 receives the request. In step 254, the backend system 104 checks the received request and, based on this, selects a signature mode from signature modes 128, 132, and 136 in step 256.

[0061] In step 258, the backend system 104 sends an indication of the selected signature mode to the mobile device 106, i.e., an indication of signature mode 136. In the corresponding step 206, the mobile device 106 receives the requested indication of the signature mode to be applied. In step 208, the mobile device initiates the creation of a signature according to the signature mode selected by the backend system 104 and predetermined in step 206. This may include forwarding the predetermined signature mode to the secure element 110. In step 210, the mobile device 106 or the App accepts the signature from the secure element 110 and sends the signature to the backend system 104 in step 212.

[0062] In the corresponding step 260, the backend system 104 receives the signature or the corresponding signed data. In step 262, the backend system 104 checks the signature and in step 264 sends successful feedback to the mobile device 104 regarding the signature and / or the action—performed based on the signed data (see for details). Figure 1 (Description of process 144). In the corresponding step 214, the mobile device 106 receives feedback.

[0063] Figure 3 Another embodiment of the method 300 for signature creation according to the present invention is illustrated in the form of a schematic sequence diagram. Method 300 may be used for... Figure 1 Specific embodiments of process 122 are described herein, and reference is made to them for the purpose of clarifying details, such as the definitions and concepts applied, for example. Figure 1 The description.

[0064] For method 300, the backend system 304 for the vehicle 302 (identified only) cooperates with the mobile device 306 of the user 308. The mobile device 306 contains an instance of an operating system and / or a secure element 310, as well as an application or App 312, which may be an App for processing a digital vehicle key for the vehicle 302, wherein the digital vehicle key is stored in the secure element 310. App 312 may be provided by the manufacturer of the vehicle 302 and is therefore also referred to as the manufacturer's app 312.

[0065] The method begins in step S01, whereby user 308 interacts with App 312, for example, to store the mentioned digital vehicle key in the secure element 310 (“owner pairing”) or to use it for key forwarding (“key sharing”). It should be explicitly stated that the method described below for signature creation is not itself associated with the digital key generated during owner pairing or key sharing. The interaction in step S01 should be understood merely as exemplary, i.e., such that the digital key generated during owner pairing or key sharing is subsequently associated with user 308’s user account via a signature (SIGN API). Step S01 may also include multiple steps. Alternatively, user input for this may be implemented in step S02.

[0066] In step S03, App (or "client") 312 sends a request to backend server 304 regarding the generation of a signature for a given application scenario, generated by the action performed by user 308 in step S01 and / or user input implemented in step S02. In step S04, backend system 304 checks the preconditions for the given application scenario. In step S05, backend server 304 generates a session ID (e.g., one-time information).

[0067] In step S06, the backend server 304 determines the signature mode to be applied. This can be done as follows: Figure 1 Implementation 100 illustrates that three signature modes are involved: a signature mode that does not require the participation of user 308, a signature mode that requires at least the consent of user 308 to participate, and a signature mode that requires at least authentication for user 308 to participate. In step S07, the backend server 304 returns the session ID and the signature mode to be applied to the client App 312.

[0068] In an optional step S08, (another) user input can be implemented (this user input may be related, for example, to the ongoing interaction between user 308 and mobile device 306, as described for step S01). In step S09, App 312 sends a request to the operating system / security element 310 to create a signature for arbitrary data (“arbitrary data” according to the CCC specification) for a digital vehicle key used for vehicle 302. The request may include the signature pattern to be applied and the data to be signed. This data may include, for example, a session ID, data relating to App 312, and / or data relating to the user input in steps S02 and S08.

[0069] If the signature pattern to be applied (one of the three signature patterns mentioned above) is such a signature pattern that requires user 308's consent to participate, then the operating system / security element 310 initiates the output of a pop-up window on the display of the mobile device 306 in step S10. In step S11, user 308 confirms receipt of the pop-up window.

[0070] In contrast, if the signature pattern to be applied requires authentication from user 308, then in step S12, the operating system / security element 310 initiates the output of a window for user authentication on the mobile device 306. In step S13, user 308 performs the required authentication by entering a PIN, password, or using facial recognition, etc.

[0071] In contrast, if the signature mode to be applied is one that does not require the participation of user 308, then one of the steps, such as step S10 or S12, is canceled. That is, no output is implemented on the user interface of mobile device 306. Instead, after the operating system / security element 310 obtains the corresponding requirement in step S09, it directly imports the signature creation, and user 308 will not know about the signature creation.

[0072] For signature creation, the operating system / secure element 310 signs the data transmitted in step S09 using the digital vehicle key stored in the secure element 310 in step S14. The data is signed as "arbitrary data". The description of the signature pattern to be applied is specified as the value of the corresponding data field in the creation of the SIGN command (i.e., using the tag (0x93)).

[0073] In step S15, the proof structure (“Data Attestation”) of the data transmitted by App 312, along with one-time framework information about the SIGN command, is returned to App 312. The proof structure contains the required SIGN data fields, including the usage tag and signature tag.

[0074] In step S16, App 312 sends a request for signature verification to backend system 304. The request includes a proof structure obtained from the secure element, including one-time frame information, App 312's client data, and optionally data relating to user input in steps S02 and / or S08.

[0075] If the predetermined signature pattern (one of the three signature patterns mentioned above) is such a signature pattern that requires authentication for user 308's participation, then the backend server 304 checks in step S17 whether user authentication has been performed. If another pattern is applied, then the server 304 will return an instruction to App 312 in step S18, indicating that an incorrect signature pattern has been applied, and terminate method 300.

[0076] If the predetermined signature pattern is such that user 308's participation requires their consent, then in step S19, backend server 304 checks whether user consent has been obtained or user authentication has been performed. If the check result is as follows, i.e., the backend signature pattern is applied, then in step S20, server 304 will return an instruction to App 312, i.e., an incorrect signature pattern is applied, and method 300 will end.

[0077] In contrast, if the predetermined signature mode is one that does not require the participation of user 308, then the checks in steps S17 or S19 are cancelled, and the backend server 304 directly imports the signature check obtained by App 312 in step S16.

[0078] To verify the obtained signature, server 304 summarizes "arbitrary data" in step S21, which undergoes signature creation in secure element 310. Here, the server may summarize data from the obtained proof structure. The data may include, for example, the App-ID of App 312 generated by the context; App data, such as the session ID (stored in backend system 304); data received by client App 312; received data relating to user input in steps S02 and / or S08; and received one-time frame information. The signature can also be known from the proof structure. As the key used for verification, backend system 304 may apply the public key portion of the digital vehicle key used for vehicle 302.

[0079] If the verification result is positive, then the backend system 304 performs an action in step S22, which should utilize signature creation or verification in method 300 to ensure security. After performing the action, the backend system 304 returns an indication to the manufacturer app 312 in step S23, indicating that the signature has been recognized as valid, and if necessary, the requirements for user consent or authentication are met, the action has been successfully performed, etc.

[0080] According to the present invention, a method for signature creation is proposed, wherein a signature is created based on the selection of one of a plurality of signature modes, and wherein at least one of the plurality of signature modes is sufficient without user involvement, i.e., without user consent or authentication (as in another mode, for example). Such a signature mode may, for example, be specified for signing data that is not highly security-related, i.e., to provide the possibility of maintaining a certain level of security without disturbing the user in such cases.

[0081] The embodiments of this invention enable the following: by providing this signature mode, and attaching it to one, two, or more other user-participatory signature modes, an optimized balance between security and user comfort is ensured for different data. For example, this invention is applicable to incorporating multiple less security-critical application scenarios into a single security scheme, where protection has been completely omitted until now because user intervention requirements (and merely obtaining user consent or approval) have been inappropriate, intrusive, costly, and complex.

[0082] The embodiments of this invention can thus contribute to the further development of flawed security solutions with improved security, without causing disadvantages to user comfort. The embodiments of this invention can improve the general level of security, which helps to enhance the usability and security of trusted digital vehicle keys, associated key management, etc., and is very important for the increasing popularity of digital vehicle keys.

[0083] Specifically, embodiments of the present invention propose extending the SIGN command according to the CCC specification or a corresponding Application Programming Interface (API). This extension can be incorporated into existing systems with minimal overhead.

[0084] List of reference numerals

[0085] 100 system

[0086] Vehicle 102

[0087] 104 backend system

[0088] 106 mobile devices

[0089] 108 users

[0090] 110 safety element

[0091] 112 Digital Vehicle Key

[0092] 120 connection

[0093] 122 Data transmission with signature generation and verification

[0094] Requirements for 124 signature mode

[0095] 126 signature creation

[0096] 128 has a signature pattern for user consent.

[0097] 130 uses tags:

[0098] No certification or accreditation instructions

[0099] 132 has a signature mode with user authentication

[0100] 134 uses the following tags:

[0101] With certification and accreditation instructions

[0102] 136 Signature mode without user participation

[0103] 138 uses tags:

[0104] Instructions for a model without accreditation or certification.

[0105] 140 Data transmission on the backend system

[0106] Inspection involving 142 users

[0107] 144 Signature Check

[0108] 146 Action Implementation

[0109] 148 confirmed

[0110] 200 methods

[0111] 202 User Input

[0112] 204 Send Signature Mode Requirements

[0113] 206 Instruction to receive signature mode

[0114] 208 signature creation

[0115] 210 Accept Signatures

[0116] 212 Send Signature

[0117] 214 Receive Feedback

[0118] 250 methods

[0119] 252 Receive Signature Mode Requirements

[0120] 254 Inspection Requirements

[0121] 256 Select Signature Mode

[0122] 258 Instructions to send signature mode

[0123] 260 receives signature

[0124] 262 Check Signature

[0125] 264 Send Feedback

[0126] 300 methods

[0127] 304 backend system

[0128] 306 mobile devices

[0129] 308 users

[0130] 310 Operating System / Security Element

[0131] 312App

[0132] Requirements for S01-S07 signature modes

[0133] Signature of S08-S15 data

[0134] Verification of S16-S23 signatures

Claims

1. A method (200) for signing data using a digital vehicle key (112), comprising the following steps: - Receive (206) an instruction to select a signature mode, wherein the signature mode is selected from at least one first signature mode (128, 132) and a second signature mode (136), wherein the at least one first signature mode (128, 132) relates to a signature with the participation of a user (108) and the second signature mode (136) relates to a signature without the participation of a user (108); - Initiate (208) signing of the data based on the selected signature mode; - Send (212) signed data; and - Receive (214) feedback regarding the signed data.

2. The method (200) according to claim 1, wherein, The at least one first signature pattern includes a signature pattern (128) relating to the consent of the user (108) and another signature pattern (132) relating to the authentication of the user (108).

3. The method (200) according to claim 1 or 2, further comprising the following steps: - Pass the selected signature mode (208) to the secure element (110); and - The security element (110) accepts (210) the signature according to the selected signature mode.

4. The method (200) according to any one of the preceding claims, wherein, The selected signature mode is the second signature mode (136), and the security element (110) performs the signature without the participation of the user (108).

5. The method (200) according to any one of the preceding claims, wherein, The signature is implemented without the user (108)'s (108's) involvement and is imperceptible to the user (108).

6. The method (200) according to any one of the preceding claims, wherein, The indication for the selected signature mode is provided with at least two different predetermined values ​​(130, 134, 138) for transmission in the information field.

7. The method (200) of claim 6, wherein the information field relates to the SIGN data field in accordance with the specifications of the Automotive Connectivity Consortium.

8. A method (250) for examining data signed using a digital vehicle key (112), comprising the following steps: - Send (258) an instruction to select a signature mode, wherein the signature mode is selected from at least one first signature mode (128, 132) and a second signature mode (136), wherein the at least one first signature mode (128, 132) relates to a signature with the participation of a user (108) and the second signature mode (136) relates to a signature without the participation of a user (108); - Receive (260) signed data; - Inspect (262) the received signed data; and - Send (264) feedback based on the inspection of the signed data.

9. The method (250) according to claim 8, further comprising the following steps: - Receive (252) the request related to the signature; - Check the requirements for receiving (254); and - Based on the inspection, a signature mode (256) is selected from at least one first signature mode (128, 132) and a second signature mode (136).

10. The method (250) according to claim 8 or 9, wherein, The inspection (262) of the signed data includes an inspection of the signature based on the digital vehicle key (112).

11. The method (250) according to any one of claims 8 to 10, wherein, The inspection (262) involves inspecting user input related to an action, and the method includes the following additional step: - An action is performed after a successful check, wherein the feedback relates to the implementation of the action.

12. A mobile device (106) configured to sign data using a digital vehicle key (112) according to the method (200) of any one of claims 1 to 7.

13. The mobile device (106) according to claim 12, including a security element (110) for storing a digital vehicle key (112).

14. A backend server (104) configured to examine data signed with a digital vehicle key (112) in accordance with the method (250) of any one of claims 8 to 11.

15. The system (100) includes: - Motor vehicle (102) is configured to store digital vehicle key (112). - The mobile device (106) according to claim 12 or 13 is configured to sign data using a digital vehicle key (112); and - The backend server (104) according to claim 14 is configured to examine data signed using the digital vehicle key (112).

Images