System and method for securely managing vehicle information

Abstract

Systems and methods for securely managing vehicle information are provided. A first digital signature associated with a vehicle may be generated based on a first public-key-private key pair, and a second digital signature associated with a mobile application may be generated based on a second public-key-private key pair. The mobile application may be associated with a mobile device operated by a user. The first digital signature and the public key of the first public-key-private key pair may be sent to and stored by the vehicle, and the second digital signature and the public key of the second public-key-private key pair may be sent to and stored on the mobile device via the mobile application. The systems and methods may determine that a request to access vehicle information has been received, and allow access to the vehicle information based on the first digital signature and the second digital signature.

Description

Technical Field

[0001] The present application relates to a system and method for securely managing vehicle information. Background Art

[0002] Some vehicles allow a user to access a user account that stores certain data associated with the user or the user's vehicle. However, if an unauthorized user gains access to a user's login credentials, such unauthorized user may be able to access the user's data and perform unauthorized actions. A more secure technique for storing a user's vehicle information is needed while still enabling the user to conveniently access his or her vehicle information. Summary of the invention

[0003] Therefore, systems and methods are disclosed herein for generating a first public key-private key pair and a second public key-private key pair by a processor associated with a server, and generating a first digital signature associated with a vehicle by the processor based on the first public key-private key pair and a vehicle identifier of the vehicle. The provided system and method can be further configured to generate a second digital signature associated with a mobile application by the processor based on the second public key-private key pair and a mobile application identifier of a mobile application associated with a mobile device operated by a user, wherein the vehicle identifier and the mobile application identifier are associated with a user profile in a database maintained by the server. The processor can send the first digital signature and the public key of the first public key-private key pair to the vehicle, and the first digital signature can be stored in a memory module associated with the vehicle. The processor can send the second digital signature and the public key of the second public key-private key pair to the mobile application, and the mobile application can facilitate the storage of the second digital signature in the local memory of the mobile device. It can be determined that a request to access vehicle information (e.g., associated with a user profile) is to be received, and access to the vehicle information can be allowed based on the first digital signature and the second digital signature.

[0004] In some embodiments, allowing access to the vehicle information based on the first digital signature and the second digital signature includes: receiving, by the processor, a first indication that the vehicle has authenticated a vehicle identifier associated with a user profile, wherein authentication associated with the first indication is performed using the first digital signature, and receiving, by the processor, a second indication that the mobile application has authenticated the mobile application associated with the user profile, wherein authentication associated with the second indication is performed using the second digital signature. The processor may allow access to the vehicle information in response to receiving the first indication and the second indication.

[0005] In some embodiments, the provided systems and methods further include: determining, by the processor, that a user associated with the user profile has selected an option for registering secure management of vehicle information, and in response to determining that the user associated with the user profile has selected an option for registering secure management of vehicle information, generating, by the processor, a first public key-private key pair and a second public key-private key pair. In some embodiments, the mobile application can be implemented at a key fob or a smartphone.

[0006] In some embodiments, the vehicle information is stored at a distributed ledger. At least one of the first public key-private key pair and the second public key-private key pair can be used to perform a transaction associated with the vehicle information on the distributed ledger, and the distributed ledger can be updated based on the transaction. In some embodiments, the first digital signature can be associated with a non-fungible token stored at the distributed ledger, wherein the non-fungible token includes historical ownership information of the vehicle and can be transferred to a new vehicle owner.

[0007] In some embodiments, determining that a request to access vehicle information has been received includes receiving login credentials and determining whether the received login credentials match login credentials of a user profile.

[0008] In some embodiments, a system for securely managing vehicle information is provided, wherein the system includes a server and a processing circuit. The server may be configured to generate a first public key-private key pair and a second public key-private key pair, and to generate a first digital signature associated with the vehicle based on the first public key pair and a vehicle identifier. The server may generate a second digital signature associated with the mobile application based on the second public key-private key pair and a mobile application identifier of a mobile application associated with a mobile device operated by a user, wherein the vehicle identifier and the mobile application identifier are associated with a user profile in a database maintained by the server, and to send the first digital signature and the public key of the first public key-private key pair to the vehicle, wherein the first digital signature may be stored in a memory module associated with the vehicle. The processing circuit may send a second digital signature and a public key of the second public key-private key pair to the mobile application, wherein the mobile application facilitates storing the second digital signature in a local memory of the mobile device. The processing circuit system may determine that a request to access vehicle information has been received, wherein the request is associated with a user profile, and access to the vehicle information based on the first digital signature and the second digital signature is allowed.

[0009] In some embodiments, a non-transitory computer-readable medium may be provided having non-transitory computer-readable instructions encoded thereon that, when executed by a processor associated with a server, cause the processor to generate a first public key-private key pair and a second public key-private key pair, and to generate a first digital signature associated with a vehicle based on the first public key-private key pair and a vehicle identifier. Execution of the instructions may cause the processor to: generate a second digital signature associated with a mobile application based on the second public key-private key pair and a mobile application identifier of a mobile application associated with a mobile device operated by a user, wherein the vehicle identifier and the mobile application identifier are associated with a user profile in a database maintained by the server, and to send the first digital signature and a public key of the first public key-private key pair to the vehicle, wherein the first digital signature may be stored in a memory module associated with the vehicle. Execution of the instructions may cause the processor to: send a second digital signature to the mobile application, wherein the mobile application facilitates storing the second digital signature in a local memory of the mobile device. Execution of the instructions may cause the processor to: determine that a request to access vehicle information has been received, wherein the request is associated with a user profile, and allow access to the vehicle information based on the first digital signature and the second digital signature. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The present disclosure according to one or more various embodiments is described in detail with reference to the following drawings. The drawings are provided for illustrative purposes only and only show typical or exemplary embodiments. These drawings are provided to facilitate understanding of the concepts disclosed herein, and these drawings should not be considered as limitations on the breadth, scope or applicability of these concepts. It should be noted that for clarity and ease of description, these drawings are not necessarily drawn to scale.

[0011] Figure 1 A block diagram of a system for securely authenticating a user and allowing access to vehicle information based on a digital signature, according to some embodiments of the present disclosure, is shown.

[0012] Figure 2 A block diagram of a system for securely authenticating a user and allowing access to vehicle information based on a digital signature, according to some embodiments of the present disclosure, is shown.

[0013] Figure 3 A block diagram of a distributed ledger according to some embodiments of the present disclosure is shown.

[0014] Figure 4A A block diagram of a system 400 for generating public-private key pairs and digital signatures is shown, according to some embodiments of the present disclosure.

[0015] Figure 4B A block diagram of a system for enabling digital signature-based access to vehicle information is shown, according to some embodiments of the present disclosure.

[0016] Figure 5 A flow chart of an illustrative process for generating a public-private key pair and a digital signature according to some embodiments of the present disclosure is shown.

[0017] Figure 6 A flow chart of an illustrative process for securely authenticating a user and allowing access to vehicle information based on a digital signature, according to some embodiments of the present disclosure, is shown. DETAILED DESCRIPTION

[0018] Figure 1 A block diagram of a system 100 for securely authenticating a user and allowing access to vehicle information based on a digital signature according to some embodiments of the present disclosure is shown. The system 100 may include a vehicle 106, a user device 102 (e.g., a mobile device, such as, for example, a smart phone or tablet, or any other suitable computing device, such as, for example, a laptop, a desktop computer, etc.) and a user device 104 (e.g., a key fob) and one or more of a cloud computing resource 112 (e.g., one or more remote servers, which may contain and / or maintain one or more databases and / or communicate therewith). Such elements of the system 100 may be configured to communicate via any suitable wireless communication path. For example, user devices 102 and 104 may be configured to communicate with vehicle 106 via short-range wireless communication technology, such as Bluetooth low energy (BLE) 108 or near field communication (NFC) 109, and user devices 102 and 104 and vehicle 106 may communicate with server 112 via a network 110 (e.g., the Internet, a local area network, a wide area network, a satellite network, a cellular network, etc.).

[0019] The system 100 may employ cryptographic techniques (e.g., any suitable algorithm for generating a public key-private key pair, generating a shared key, generating a digital signature, a hashing algorithm, etc.). Such cryptographic techniques may be used to manage and verify the identity of a user requesting vehicle information (e.g., vehicle information associated with a user's vehicle 106), based on securely stored cryptographic keys and digital signatures, and to allow authenticated users to access the vehicle information and / or to allow transactions to be performed in conjunction with the vehicle information. In some embodiments, allowing access to the vehicle information may include generating the vehicle information for presentation at any suitable device via an application stored at least in part in a memory module of the vehicle 106 and executed at the vehicle 106, etc., such as via a mobile application executed at the user device 102 or the user device 104. A user may be allowed to manage such vehicle information, such as allowing or revoking access to the information of certain entities. In some embodiments, allowing access to the vehicle information may include enabling transactions to be processed along various payment platforms or payment networks (e.g., to enable the purchase of vehicle accessories or vehicle parts, and to track the delivery and integrity of such accessories or parts). In some embodiments, a user who accesses vehicle information in association with a mobile application or via a vehicle may be allowed to transmit such vehicle information to another party (e.g., an insurance company, a potential vehicle purchaser, a vehicle manufacturer, etc.) for use in a commercial transaction. For example, once a user is allowed access to his or her vehicle information, he or she may allow an insurance company to securely access the information in order to generate an insurance quote. The secure nature of the encryption techniques utilized herein may prevent hackers or bad actors from accessing vehicle information stored, for example, at a distributed ledger.

[0020] In some embodiments, vehicle information can be stored at a distributed ledger, and the user can access the distributed ledger from a user device 102, a user device 104, a vehicle 106, or any other suitable computing device. In some embodiments, each node of the system 100 can be configured to store a distributed ledger. In some embodiments, after the user's identity is authenticated and verified by the system 100, the user can be allowed to access the distributed ledger via a server 112. In some embodiments, the user can be a driver or operator of a vehicle 106, or any other suitable entity (e.g., a business entity, such as, for example, an insurance company, a vehicle manufacturer, etc.). In some embodiments, vehicle information can include a driving history of a vehicle 106, past and current ownership information of a vehicle 106, user information, vehicle-related data, and / or any other suitable information. In some embodiments, vehicle information can be stored in a distributed ledger in the form of a non-substitutable token (NFT), and can be transferred to one or more other parties. In some embodiments, a distributed ledger can store current traffic information or road condition information for use by any suitable number of vehicles. For example, a user may earn rewards by posting traffic information to a distributed ledger for consumption by other users associated with the corresponding vehicle and having access to the distributed ledger. In some embodiments, a user may be allowed to access data related to the user's personal preferences stored at the distributed ledger, e.g., desired vehicle settings, preferred music options. In some embodiments, the distributed ledger may be used to facilitate ride sharing or vehicle sharing applications. For example, when accessing the distributed ledger, a user may be allowed to access available ride services via a ride sharing platform.

[0021] In some embodiments, the server 112 may be used to associate one or more user accounts (e.g., each user account is associated with login credentials including a specific user ID stored at the server 112, which specific user ID may be associated with a vehicle manufacturer or dealer) with a vehicle 106 (e.g., associated with a specific vehicle identifier), associate one or more user profiles with a user account, and / or associate one or more user devices and / or mobile applications (associated with a specific mobile application identifier and a mobile device operated by the user) with a specific user account or profile. The server 112 may enable a user to log into a user account at the vehicle 106, and in response to logging into the user account, retrieve a user profile associated with the user account (e.g., from the server 112 or the vehicle 106), and cause the user profile to be loaded at the vehicle 106. In some embodiments, user credentials may be generated and stored at the server 112 and login may be enabled for a specific user (e.g., by comparing the received credentials with stored credentials associated with the user account).

[0022] In some embodiments, the user profile corresponds to or is otherwise associated with a user account of a vehicle manufacturer. Vehicle identification information and user device information may be included in the user profile. In some embodiments, user device 102 or user device 104 may be configured to implement a mobile application (e.g., provided by and / or associated with a vehicle manufacturer) that allows a user to access the user profile and specify certain settings or preferences for the user profile and / or obtain vehicle information.

[0023] In some embodiments, user devices 102 and / or 104 can be operated by a user to perform various functions related to vehicle 106 (e.g., remote starting, unlocking and locking doors or hatches, pairing with a media system of vehicle 106, starting or turning vehicle 106, signaling an emergency, etc.) via wireless or wired communication paths.

[0024] Figure 2 A block diagram of a system 200 for securely authenticating a user and allowing access to vehicle information based on a digital signature according to some embodiments of the present disclosure is shown. The system 200 includes a vehicle 206, which may correspond to Figure 1 The vehicle 106 of the system 200, and the user device 202, which may correspond to the user device 102 (e.g., a mobile device, such as, for example, a smart phone) and / or a user device 204 (such as, for example, a key fob). The vehicle 206 may communicate with the server 212, the user device 202, and the user device 204 via one or more networks 210 or any other suitable network (e.g., short-range wireless communication). In some embodiments, each element of the system 200 may be configured to execute a vehicle application (e.g., provided by the manufacturer of the vehicle 206) to perform the techniques described above and below, for example, to manage and verify the identity of a user requesting vehicle information based on securely stored encryption keys and digital signatures, to securely provide vehicle information to the user, and / or to allow transactions to be performed in conjunction with vehicle information. The vehicle 206 may be an automobile (e.g., a coupe, a sedan, a truck, an SUV, a bus), a motorcycle, an aircraft (e.g., a drone), a vessel (e.g., a ship), or any other type of vehicle. In some embodiments, the vehicle 206 may be configured to operate autonomously or semi-autonomously.

[0025] The vehicle 206 may include a processing circuit 216, which may include a processor 218 and a memory 220. The processor 218 may include a hardware processor, a software processor (e.g., a processor emulated using a virtual machine), or any combination thereof. In some embodiments, the combination of the processor 218 and the memory 220 may be referred to as the processing circuit 216 of the vehicle 206. In some embodiments, the separate processor 218 may be referred to as the processing circuit 216 of the vehicle 206. The memory 220 may include a hardware element for non-transient storage of commands or instructions that, when executed by the processor 218, cause the processor 218 to operate the vehicle 206 according to the embodiments discussed above and below. The processing circuit 216 may be communicatively connected to a component of the vehicle 206 via one or more wires or via a wireless connection. The memory 220 may be a memory module configured to store a digital signature and / or a vehicle identifier and / or a public key associated with the vehicle 206.

[0026] Processing circuitry 216 may be communicatively connected to input interface 226 (e.g., a steering wheel, touch screen display, buttons, knobs, microphone, or other audio capture device, etc.) via input circuitry 224. In some embodiments, the driver of vehicle 206 may be allowed to select specific settings via input interface 226 in conjunction with the operation of vehicle 206. Input interface 226 may be communicatively connected to one or more cameras 225, which may be configured to capture the interior or exterior environment of vehicle 206. Such images may be sent to processing circuitry 216 and used, for example, to detect obstacles or vehicles near vehicle 206, for biometric purposes (e.g., facial recognition or fingerprint recognition) to verify the driver of vehicle 206, and the like. In some embodiments, the vehicle 206 may include one or more sensors positioned at various locations of the vehicle 206, and such sensors may be one or more of various types, such as image sensors, ultrasonic sensors, radar sensors, LED sensors, LIDAR sensors, etc., configured to measure the distance between the vehicle 206 and objects in the vehicle's surroundings (e.g., by outputting light or radio wave signals and measuring the time for a return signal to be detected and / or the strength of the return signal, and / or performing image processing on images of the vehicle's surroundings captured by the image sensor).

[0027] Processing circuit 216 may be communicatively connected to display 232 and speaker 234 via output circuit 222. Display 232 may be located at a dashboard of vehicle 206 and / or a head-up display at a windshield of vehicle 206. Display 232 may include an LCD display, an OLED display, an LED display, or any other type of display. Display 232 may be configured to display an optional identifier associated with a user profile of a particular user account associated with vehicle 206. Speaker 234 may be located anywhere within the cabin of vehicle 206, for example, at a dashboard of vehicle 206, on an interior portion of a door, etc., and may be configured to provide audio output to a driver and / or passenger of vehicle 206.

[0028] Processing circuit 216 may be communicatively connected to communication circuit 227. Communication circuit 227 may include wireless network transceiver 238, which may include any suitable hardware and / or software operable to send and receive wireless signals between vehicle 206 and external devices, such as, for example, a network or user device (e.g., user device 202, user device 204, server 212 and / or Wi-Fi access point and / or satellite) and / or any other suitable computing device. Wireless network transceiver 238 may include an antenna and other control circuits (e.g., protocol converter, rate converter, signal converter), or any combination thereof. Wireless network transceiver 238 may include one or more components to facilitate communication via any suitable network or communication method (e.g., the Internet, short-range wireless communication, etc., such as, for example, Bluetooth, BLE, NFC, etc.). For example, wireless network transceiver 238 may be configured to access the Internet, a local area network, a wide area network, a Bluetooth-enabled device, an NFC-enabled device, any other suitable device using any suitable protocol, or any combination thereof. In some embodiments, the wireless network transceiver 238 may include a sensor configured to advertise a vehicle identifier (eg, via a BLE link).

[0029] Processing circuit 216 is communicatively connected to battery system 228, which can be configured to provide power to one or more of the components of vehicle 206 during operation. In some embodiments, vehicle 206 can be an electric vehicle or a hybrid electric vehicle, and / or can be configured as an autonomous or semi-autonomous vehicle. Processing circuit 216 is communicatively connected to GPS system 230 or other positioning device of vehicle 206, wherein the driver can interact with GPS system 230 via input interface 226. GPS system 230 can communicate with one or more satellites and / or servers away from vehicle 206 (e.g., via communication circuit 227) to determine the location of vehicle 206 and provide navigation directions to processing circuit 216. As another example, the positioning device can operate on terrestrial signals (such as cellular phone signals, Wi-Fi signals, or ultra-wideband signals) to determine the location of vehicle 206. The determined location can be in any suitable form, such as geographic coordinates, street addresses, nearby landmarks such as the identification of the nearest charging station, or a marked location associated with vehicle 206 (e.g., the location of the user's home stored in memory 220).

[0030] It should be understood that Figure 2 Only some components of the vehicle 206 are shown, and it should be understood that the vehicle 206 also includes other elements commonly found in vehicles (e.g., electric vehicles), such as motors, brakes, wheels, wheel controls, turn signals, windows, doors, etc.

[0031] The user device 202 may be, for example, a smart phone, a tablet, or any suitable personal computing device operable to communicate with the vehicle 206, the user device 204, and the server 212, for example, via a wireless network transceiver 260. In some embodiments, the user device 202 may be configured to communicate with the vehicle 206 via a wired connection (e.g., a USB connection or other data cable).

[0032] The user device 202 may include a processing circuit 240, a processor 242, a memory 244, which may be implemented in a manner similar to the processing circuit 216, the processor 218, and the memory 220, respectively. The user device 202 may further include a display 246, a microphone 248, an input / output (I / O) circuit 250, a speaker 252, a camera 254, and a GPS 256, which may be implemented in a manner similar to the display 232, the input interface 226, the speaker 234, the output circuit 222 and the input circuit 224, the speaker 234, the camera 225, and the GPS 230. The communication circuit 258 may be implemented in a manner similar to the communication circuit 227 of the vehicle 206. The communication circuit 258 may include a wireless network transceiver 260, which may include one or more components configured to receive and transmit signals using various communication technologies. For example, wireless network transceiver 260 may enable user device 202 to communicate with vehicle 206 via a first communication path (e.g., BLE, NFC, or other short-range communication technology), and wireless network transceiver 260 may enable user device 202 to communicate with server 212 via a second communication path (e.g., network 210, such as, for example, the Internet, a satellite network, etc.). In some embodiments, a mobile application may be implemented at user device 202, and may facilitate storage of a digital signature and / or public key associated with the mobile application and / or mobile application identifier in local memory 244 of user device 202. For example, the mobile application may direct storage of the digital signature and / or public key to local memory 244.

[0033] The user device 204 may be, for example, a key fob. The user device 204 may include a processing circuit 262, a processor 264, a memory 266, an I / O circuit 268, a communication circuit 270, and a wireless network transceiver 272. The key fob 204 may include one or more buttons or other features for receiving tactile input from a user. For example, in some embodiments, the key fob 204 includes a plurality of buttons (e.g., two, three, four, or more than four buttons), which correspond to functions or commands, respectively. The key fob 204 may include a battery for providing power, an antenna for sending and receiving signals, and a processing circuit 262 that can convert a user selection (e.g., a button press) into an electrical signal and then (e.g., via an antenna) into a wireless signal. The wireless network transceiver 272 may be configured to enable the user device 204 to communicate with the vehicle 206 via a first communication path (e.g., BLE, NFC, or other short-range communication technology), and the wireless network transceiver 272 may enable the user device 202 to communicate with the server 212 via a second communication path (e.g., a network 210, such as, for example, the Internet, a satellite network, etc.). In some embodiments, a mobile application may be implemented at the user device 204, and it may be advantageous to store a digital signature and / or public key associated with the mobile application and / or mobile application identifier in the local memory 266 of the user device 202.

[0034] The server 212 may include a plurality of servers configured to remotely provide cloud computing resources (e.g., storage, processing, software applications, etc.) to other components of the system 200, such as the user device 202, the user device 204, and / or the vehicle 206. The server 212 may be configured to maintain one or more databases. In some embodiments, the server 212 may be associated with the manufacturer of the vehicle 206 and may be configured to store (e.g., a cloud-based storage system, such as in the memory 278 or a database associated with the server 212) information related to each vehicle sold by the manufacturer and to the owner of each vehicle, such as a login credential associated with the vehicle owner's user account and / or user profile, which may be generated and provided to the user when the user purchases the vehicle 206; user permissions and positions or specific user accounts or user profiles; user preferences regarding specific user accounts or profiles, etc. Such information may be stored in any suitable format, such as, for example, a centralized database, a distributed ledger, a lookup table, a tag set, one or more ASCII characters or words (e.g., in a text file), any other format, or any combination thereof.

[0035] Server 212 may include processing circuitry 274, including processor 276 and memory 278, communication circuitry 280, and wireless network transceiver 282. Processing circuitry 274 may be implemented in a similar manner to processing circuitry 216, except that processing circuitry 274 may be configured to utilize a processor that provides a large amount of computing power, and server 212 may be configured to include storage devices with a large amount of capacity and memory 278. In some embodiments, server 212 may include a collection of servers, and processing circuitry 274 may be distributed across multiple servers.

[0036] The server 212 may be configured to generate a public key-private key pair associated with the vehicle 206 and a public key-private key pair associated with the user device 202, and may be configured to generate a corresponding digital signature to be sent to the vehicle 206 and the user device 202 for authenticating the identity of the user. In some embodiments, the server 212 may be configured to store each public key-private key pair, vehicle identifier, mobile application identifier, and corresponding digital signature, for example, in association with a specific user account or user profile. In some embodiments, the user device 202 or 204 may be configured to store the public key and digital signature received from the server 212, and the vehicle 206 may be configured to store the public key and digital signature received from the server 212.

[0037] Figure 3 A block diagram of a distributed ledger 300 according to some embodiments of the present disclosure is shown. In some embodiments, the distributed ledger 300 can be a decentralized shared database implemented as a blockchain distributed ledger, where multiple network-connected computing devices (e.g., vehicle 206, server 212, user device 202) can store the distributed ledger 300 locally or otherwise be granted access to the distributed ledger. The distributed ledger 300 may include multiple blocks 302, 304, 306, each block including data records related to a corresponding transaction. The distributed ledger 300 can be updated via continuous or peer-to-peer communication between nodes with access rights to the distributed ledger 300. Users may be allowed to access vehicle information through the distributed ledger 300.

[0038] Cryptographic techniques (e.g., hash functions, public-private key pairs) may be employed to ensure that the sequence of transactions on each copy of the distributed ledger 300 matches. In some embodiments, one or more consensus mechanisms (e.g., proof of work, proof of stake, Byzantine failure) may be employed in association with the distributed ledger 300 to verify transactions on the distributed ledger 300. Any suitable number of nodes may be required to verify transactions for recording the distributed ledger 300 (e.g., each node in the network, a majority of nodes in the network, specific nodes in the network, etc.). In some embodiments, the distributed ledger 300 may be permissionless or public (e.g., any node may access the distributed ledger 300 and submit transactions or perform verification) or the distributed ledger 300 may be permissioned or private (e.g., the server 212 may only invite certain identified or authenticated nodes to interact with the distributed ledger 300). Private blockchains may be more centralized and restricted, and less consensus-based, than public blockchains.

[0039] Each of the blocks 302, 304, 306 may include data associated with the transaction (e.g., vehicle information related to a particular vehicle), a timestamp associated with the transaction, and a calculated hash value associated with the transaction (e.g., calculated by inputting the vehicle information into a hash function). Although only three blocks are shown, it will be appreciated by one of ordinary skill in the art that any number of blocks may be stored at the distributed ledger 300. In some embodiments, a hash function (e.g., SHA-1, SHA-2, SHA-256) and a timestamp may be employed to verify transactions on the distributed ledger 300 and ensure the integrity of the blockchain. Each block 302, 304, 306 may be linked to other blocks because each new block may include a concatenation of hash values ​​of previous blocks representing previous transactions. For example, the value of the hash value B of the block 304 may depend at least in part on the hash value A of the block 302, and the value of the hash value C of the block 306 may depend at least in part on the hash value B of the block 304. Such features of the distributed ledger 300 facilitate the immutable nature of the distributed ledger 300, for example, if the data in a block is tampered with, other nodes will not be able to recalculate the hash values ​​to verify that all hash values ​​in the blockchain are correct.

[0040] In some embodiments, a public-private key pair can be used to verify data submitted to the distributed ledger 300 by a user with a particular private key, so that data encrypted by the private key (e.g., a hash value of the data) can be decrypted with the public key of the public-private key pair, and a digital signature can be generated using the public-private key pair. Other nodes on the distributed ledger 300 can perform calculations to verify the signer. In some embodiments, the public key can correspond to an address on the distributed ledger 300 to which the data can be sent. A timestamp can be used to distinguish transactions on the distributed ledger 300. In some embodiments, alternatively or in addition to being stored at the distributed ledger 300, vehicle information can be stored on a centralized database.

[0041] In some embodiments, NFTs and / or smart contracts (e.g., for automatic execution if conditions specified in the smart contract occur) can be stored at the distributed ledger 300 for execution. For example, an NFT can include an immutable token indicating each previous owner (e.g., a particular vehicle has 3 previous owners; a celebrity previously owned the vehicle, etc.). In some embodiments, smart contracts can be used in conjunction with NFTs, for example, to automatically provide value to one party when a transaction occurs regarding a vehicle specified in the NFT. In some embodiments, smart contracts can be used to enable a user to perform transactions related to charging his or her electric vehicle, for example, paying for charging his or her vehicle at a charging station.

[0042] Figure 4A A block diagram of a system 400 for generating a public key-private key pair and a digital signature according to some embodiments of the present disclosure is shown. The system 400 depicts a user 401 within a vehicle 406, where the user 401 can be associated with a user device 402, and the vehicle 406 and the user device 402 can communicate with a server 412 (e.g., via a network 210).

[0043] The processing circuit 274 of the server 212 (which may correspond to the server 412) may generate a public key-private key pair 410 including a public key 411 and a private key 413 and a public key-private key pair 414 including a public key 415 and a private key 417. Each public key-private key pair may be generated using any suitable encryption algorithm or technique (e.g., RSA, ECC asymmetric algorithm, etc.). The public key-private key pair 410 may be associated with the vehicle 406 (which may correspond to the vehicle 206), and the public key-private key pair 414 may be associated with a mobile application, for example, a mobile application provided by the manufacturer of the vehicle 406 and executed at least in part on the mobile device 402 by the processing circuit 240 of the user device 202 or the processing circuit 262 of the user device 204 (either of which may correspond to the user device 402). In some embodiments, each public key and private key may include a corresponding numeric string or alphanumeric string. In some embodiments, a message encrypted with one of public key 411 or private key 413 can be decrypted only with the other of public key 411 or private key 413, and a message encrypted with public key 415 or private key 417 can be decrypted only with the other of public key 415 or private key 417.

[0044] In some embodiments, the generation of the public key-private key pair 410 and 414 may be performed in response to receiving a registration or login request from a user 401 (e.g., the owner of the vehicle 406). For example, the processing circuit 240 of the user device 202 (or the processing circuit 216 of the vehicle 206 or the processing circuit of any suitable computing device operated by the user 401) may receive input of login credentials, including a user ID 419 and a password 421, which may be entered by the user 401 through the I / O circuit 250 or via the input interface 226 of the vehicle 406 (e.g., via text entry, biometric recognition, etc.). In some embodiments, the manufacturer of the vehicle 406 may provide instructions, such as by the server 212, via sending a message to the email address of the user 401, to enable the user 401 to create a user account associated with the login credentials 419, 421. In some embodiments, the user ID 419 of the user account or profile may correspond to a unique identifier that includes an alphanumeric string, or to a username that includes a unique identifier of the user name.

[0045] In some embodiments, the server 412, upon receiving the login credentials 419, 421 from the wireless network transceiver 260 of the user device 402 (e.g., via the network 210), can determine whether the login credentials 419, 421 associated with the user 401 are associated with the authenticated user account or user profile indicated at 423. For example, the processing circuitry 274 of the server 212 can compare the received login credentials 419, 421 with stored credentials stored in the memory 278 of the server 212 or other cloud storage device, and determine based on the comparison whether the credentials match the stored entry for the particular user account or user profile indicated at 423. In some embodiments, the user device 402 or the vehicle 406 can determine whether the login credentials 419, 421 associated with the user 401 are associated with the authenticated user account or user profile indicated at 423.

[0046] In some embodiments, the generation of public key-private key pairs 410 and 414 may be performed in response to receiving an affirmative selection 422 associated with indication 420 from user 401 to opt-in to a secret management service provided by one or more elements of system 400. For example, a user interface including indication 420 and affirmative selection 422 may be presented at user device 402 or vehicle 406 in response to user 401 being authenticated at server 212. Such a user interface may be generated for presentation in response to server 212 determining that a user profile associated with the verified login credentials is authenticated. In some embodiments, the first time user 401 logs into his or her account, he or she may be automatically registered for the secret management service.

[0047] In some embodiments, server 412 may generate or otherwise receive a vehicle identifier 424 (e.g., a UUID comprising an alphanumeric string) associated with vehicle 406 and a mobile application identifier 426 (e.g., a UUID comprising an alphanumeric string) associated with a mobile application running on user device 402. In some embodiments, one or more of vehicle identifier 424 and mobile application identifier 426 may be generated and / or assigned to vehicle 406 during manufacture of vehicle 406, and a user account or user profile of the vehicle owner indicated at 423 is generated when purchasing vehicle 406 or when registering for the secret management service indicated at 420.

[0048] The server 412 may be configured to generate a digital signature 430 associated with the vehicle 406 and a digital signature 432 associated with the mobile application (e.g., provided by the manufacturer of the vehicle 406). For example, a digital signature generator 428 may be employed to generate the digital signature 430 using the vehicle identifier 424 and the private key 413 associated with the vehicle 406, and a digital signature generator 428 may be employed to generate the digital signature 432 using the private key 417 associated with the vehicle 406 and the mobile application identifier 426. The digital signature generator 428 may correspond to any suitable digital signature encryption algorithm or technology (e.g., DSA, ECDSA, EdDSA, RSA, Schnorr-based protocol). The server 412 may send the public key 411 and the digital signature 430 to the vehicle 406, and the public key 411 and the digital signature 430 may be stored at a memory module of the vehicle 406. The server 412 may send the public key 415 and the digital signature 432 to the user device 402 at any suitable time. The mobile application executing at the user device 402 may be configured to facilitate storage of the public key 415 and the digital signature 432 at the user device 402 .

[0049] In some embodiments, when generating the digital signature 430, the digital signature generator 428 may employ a cryptographic hash function (e.g., SHA-256, SHA-512, MD5, SHA-1) to generate a hash value of the vehicle identifier 424 for use in performing an authentication sequence associated with the user 401, such as between the vehicle 406 and the server 412. A cryptographic hash function may be understood as a function that accepts a string of arbitrary length and outputs a hash value or fingerprint of a fixed-length string of characters (e.g., numeric or alphanumeric), and which is deterministic, e.g., the same repeated input produces the same output. The obtained hash value of the vehicle identifier 424 may be combined with the private key 413 (e.g., encrypted by the private key) to generate the digital signature 430, and the digital signature 430 may be sent to the vehicle 406 (e.g., separately or together with the public key 411). To generate digital signature 432, a hash value of mobile application identifier 426 may be obtained and combined with private key 417 (e.g., encrypted by the private key), and digital signature 432 may be sent to the mobile application (e.g., separately or together with public key 415). In some embodiments, neither private key 413 nor private key 417 is sent from server 412 to any other device, but instead is stored at server 412 and kept secret.

[0050] Figure 4BA block diagram of a system 400 for allowing access to vehicle information based on a digital signature according to some embodiments of the present disclosure is shown. A server 412 may receive a request to access vehicle information associated with a vehicle 406 from a user associated with a user account or user profile indicated at 423. In some embodiments, such vehicle information may be stored at the server 412 and / or the distributed ledger 444 (which may correspond to the distributed ledger 300), including blocks 458, 460, 462 (which may correspond to blocks 302, 304, 306). Such a request to access vehicle information may be received from, for example, a user device 402 or a vehicle 406, such as based on receiving a selection of option 433. Since the user account or user profile indicated at 423 has previously registered with the secret management service associated with the indicator 420, the server 412 may (at 446 and 448) request a mobile application (e.g., a mobile application running on the user device 402 and the vehicle 406) to verify the corresponding digital signatures 430 and 432 for the user account or user profile indicated at 423. For example, the request associated with 446 may include an indication of a vehicle identifier 424 associated with the account or profile indicated at 423, and the request associated with 446 may include an indication of a mobile application identifier 426 associated with the account or profile indicated at 423. In some embodiments, selection of option 433 may correspond to a request to access recent vehicle information transactions on distributed ledger 444.

[0051] In determining whether to provide the requested vehicle information to user 401, server 412 may wait for an indication that each of digital signatures 430 and 432 has been verified by vehicle 406 and user device 402, respectively (at 450 and 452). The entity receiving the message (e.g., user device 402 or vehicle 406) may perform an authentication or verification function on the received message to authenticate user 401 associated with the user profile requesting the vehicle information and ensure the integrity of the message (e.g., including vehicle identifier 424 or mobile application identifier 426). For example, vehicle 406 may locally calculate a hash value of vehicle identifier 424 using a cryptographic hash function (e.g., the same hash function used by server 412 during generation of digital signature 430) and decrypt the previously received digital signature 430 using the previously received public key 411 to extract the hash value associated with the previously received digital signature 430. The vehicle 406 may determine whether the calculated hash value matches the hash value extracted from the digital signature 430; if there is a match, the vehicle 406 may provide an indication to the server 412 indicating that the digital signature 430 has been verified (at 452). On the other hand, if such hash values ​​do not match, access to the requested vehicle information may be denied because the mismatch indicates that the private key 413 stored at the server 412 and used to generate the digital signature 430 (stored at the server 412 and the vehicle 406) does not correspond to the public key stored in the memory module associated with the vehicle 406.

[0052] Similarly, the mobile application running at the user device 402 can locally calculate a hash value for the mobile device identifier 426 using a cryptographic hash function (e.g., the same hash function used by the server 412 during the generation of the digital signature 432), and decrypt the previously received digital signature 432 using the previously received public key 415 to extract the hash value associated with the previously received digital signature 432. The mobile application can determine whether the calculated hash value matches the hash value extracted from the digital signature 432; if there is a match, the vehicle 406 can provide an indication to the server 412 indicating that the digital signature 432 has been verified (at 450). On the other hand, if such hash values ​​do not match, access to the requested vehicle information can be denied because the mismatch indicates that the private key 417 stored at the server 412 and used to generate the digital signature 432 (stored at the server 412 and in conjunction with the mobile application) does not match the public key 415 stored at the local memory of the user device 402, for example, where the mobile application can facilitate such storage. Thus, even if an unauthorized third party were to obtain the login credentials of user 401, such access may be prevented if the third party attempts to access the account of user 401 via a mobile application implemented on the unauthorized third party's user device. For example, if the mobile application identifier associated with the mobile application implemented on the unauthorized third party's user device does not match the mobile application identifier associated with the instance of the mobile application of user device 402 of user 401, then indication 450 may not be sent to server 450 due to the mismatch between the digital signature associated with the mobile application identifier stored in the user profile of user 401 and the digital signature calculated locally by the unauthorized third party's mobile application.

[0053] In some embodiments, prior to requesting (at 448) verification of digital signature 430 and / or prior to requesting (at 450) verification of digital signature 432, or as part of one or more of such verifications, user 401 may be prompted to confirm a request for vehicle information indicated at 433. For example, user device 402 (e.g., corresponding to a user device ID stored in conjunction with a user profile of user 401) and / or vehicle 406 (e.g., via display 232) may prompt user 401 to confirm a request for vehicle information indicated at 433 as an additional layer of security. In some embodiments, a mobile application implemented at user device 402 and / or vehicle 406 may refrain from performing verification of the corresponding digital signature until a response to such one or more prompts is received. In some embodiments, one or more of such prompts may be sent via an electronic message, e.g., a text message or email account associated with the user profile, for user confirmation. In some embodiments, if the user device 402 is determined to be within a predefined proximity of the vehicle 406 and / or the user device 204 (e.g., based on the signal strength or RSSI exchanged between the user device 402 and the vehicle 406 and / or the user device 204), the user 401 may not be prompted to confirm the request for vehicle information. As another example, if the user 401 is determined to be in the vehicle 406, and the vehicle 406 is determined to be turned on, the vehicle 406 may prompt the user on the display 422 to confirm that he or she is requesting vehicle information. In some embodiments, access to vehicle information may be provided only if it is determined that the user device 402 implementing the mobile application is within a threshold distance from the vehicle 406.

[0054] At 454, in response to receiving indications 450 and 452 (and optionally having previously authenticated user 401 based on received login credentials 419 and 421), server 412 may retrieve vehicle information 456 requested by user 401 from distributed ledger 444 (or any other suitable database). For example, an indication of vehicle identifier 424 and / or mobile application identifier 426 may be stored at distributed ledger 444 in conjunction with the vehicle information, and server 414 may retrieve the vehicle information associated with vehicle 406 requested at 433. In some embodiments, the vehicle information may be stored at distributed ledger 444 in any suitable format (e.g., JSON format) and may be encrypted using any suitable protocol. In some embodiments, the retrieved vehicle information 456 may be stored at server 412 and / or sent to vehicle 406 and / or user device 402 (e.g., requesting device). In some embodiments, data access may be refreshed or revoked based on policies for a particular use case. In some embodiments, the data may not be returned to the vehicle 406 or the user device 402 , and may instead be returned to the server 412 .

[0055] In some embodiments, the Edwards curve digital signature algorithm (EdDSA) protocol can be used, and more specifically, the Ed25519 protocol is used to generate digital signatures 430 and 432 (as well as public key-private key pairs 410, 414). EdDSA utilizes the unique characteristics of elliptic curves, more specifically, the difficulty of solving the elliptic curve discrete logarithm problem. In order to generate digital signatures 430 and 432 (as well as public key-private key pairs 410, 414), the Ed25519 protocol utilizes various parameter values ​​of elliptic curves. Such parameters and the type of elliptic curves used can be established between the server 412, the vehicle 406, and the mobile application associated with the mobile application identifier 426. The server 412 can generate a private key 413 (e.g., 256 bits) and calculate points on the elliptic curve based on the private key 413 and the parameter value G, the generating point or base point of the elliptic curve. Such a calculated point on the elliptic curve may correspond to a public key 411 (e.g., 68 characters and 256 bits) of a public key-private key pair 410. For example, server 412 may calculate (X V ,Y V ) on the elliptic curve and sends point V to vehicle 406, and server 412 can calculate (X M ,Y M )’s elliptic curve and sends point M to user device 302.

[0056] In the Ed25519 protocol, the digital signature generator 428 may generate a digital signature 430 (e.g., 512 bits) by computing a hash value of the private key 413 using a cryptographic hash function, and the computed hash value of the private key 413 may be hashed with the vehicle identifier 424 to generate a deterministic random value r v The value R corresponding to the point on the elliptic curve v Can be based on the random value r v and the generating point G is calculated, and another value S v Can be based on the random value r v , private key 413 (or its hash value) and R v The hash value of , the public key 413 and the vehicle identifier 424 are generated. Based on such calculations, a digital signature 430 can be generated and sent to the vehicle 406, for example (R v ,S v ).

[0057] Similarly, in the Ed25519 protocol, the digital signature generator 428 may generate the digital signature 432 by calculating the hash value of the private key 417 using a cryptographic hash function, and the calculated hash value of the private key 417 may be calculated with the mobile application identifier 426 to generate a deterministic random value r m The value R corresponding to the point on the elliptic curve m Can be based on the random value r m and the generating point G is calculated, and another value S m Can be based on the random value r m , private key 417 (or its hash value) and R m The hash value of , the public key 415 and the mobile application identifier 426 are generated. Based on such calculations, a digital signature 432 can be generated and sent to the user device 402, such as (R m ,S m ). In some embodiments, the vehicle 406 may be configured to locally store the public key 411 and the digital signature 430 , and the mobile application associated with the user device 402 may be configured to locally store the public key 415 and the digital signature 432 .

[0058] In the context of the Ed25519 protocol, in response to receiving request 446, vehicle 406 may generate a point G*S by determining v Is it equal to R v +(Public Key 411)*(R v The vehicle 406 may have previously received a digital signature in the form of (R v ,Sv ), may have previously received the public key 411, may have previously stored the vehicle identifier 424, may have access to the established elliptic curve parameters including the generation point G, and may utilize these values ​​to perform the above-described verification. The verification may utilize the same cryptographic hash function used by the server 412 in generating the digital signature 430.

[0059] Similarly, in the context of the Ed25519 protocol, in response to receiving request 446, the mobile application may generate a point G*S by determining m Is it equal to R m +(Public Key 415)*(R m The mobile application may have previously received a digital signature in the form of (R m ,S m ) and may have previously received public key 415, may have previously stored mobile application identifier 426 and / or received mobile application identifier 426 at 448, may have access to established elliptic curve parameters including generation point G, and may utilize these values ​​to perform the above-described verification. The verification may utilize the same cryptographic hash function used by server 412 in generating digital signature 432. Processing may proceed to 454 in response to verifying each of digital signature 430 and digital signature 432.

[0060] Exemplary program code for generating a public key-private key pair 410, 414 is provided below:

[0061] import ed25519

[0062] privKey,pubKey=ed25519.create_keypair()

[0063] print("Private key(32bytes):",privKey.to_ascii(encoding='hex'))

[0064] print("Public key(32bytes):",pubKey.to_ascii(encoding='hex'))

[0065] In some embodiments, the public keys 411 and 415 received by the vehicle 406 and the mobile application executed at the user device 402, respectively, can be stored in a local secure environment of each of the vehicle 406 and the user device 402, such as in conjunction with a near field communication (NFC) environment. In some embodiments, the public keys 411 and 415 can be sent to the vehicle 406 and the user device 402, respectively, over the network 210 using an https secure connection.

[0066] In some embodiments, a two-way authentication process may be utilized to facilitate encrypted transactions between the user device 402 and the vehicle 406, for example, where network connectivity with the server 412 is an issue. For example, short-range wireless communication technology may be utilized to share data between the user device 402 and the vehicle 406. In some embodiments, if only local data access is available, one or more of the vehicle 406 and the user device 402 may access local data for basic functionality.

[0067] Figure 5 A flow chart of an exemplary process 500 for generating a public key-private key pair and a digital signature according to some embodiments of the present disclosure is shown. The process 500 may be performed at least in part by the processing circuit 274 of the server 212 and / or the processing circuit 240 of the user device 202 and / or the processing circuit 216 of the vehicle 206.

[0068] At 514, processing circuitry 274 of server 212 may receive login credentials 419, 421 and / or request 420 to initiate registration of user 401 for a privacy management service provided, for example, by the manufacturer of vehicle 406. Such credentials and / or requests may be received from, for example, user device 402 or vehicle 406.

[0069] At 516, processing circuitry 274 of server 212 may authenticate user 401. For example, processing circuitry 274 may compare the received login credentials associated with 401 with the login credentials stored in memory 278, and in response to determining that the received credentials match the credentials of a particular user profile or user account, processing circuitry 274 may authenticate user 401. In some embodiments, mobile application identifier 426 and vehicle identifier 424 may be associated with the authenticated user profile and retrieved from memory 278 by processing circuitry 274, and a particular timestamp associated with the login may be generated. In some embodiments, the vehicle identifier and mobile application identifier may be associated with a particular user profile in a database maintained by server 412.

[0070] At 518, after authenticating the user profile or user account of user 401 and / or receiving request 402, processing circuitry 274 of server 212 may employ cryptographic techniques to generate a digital public key-private key pair 410 associated with vehicle 406 and a digital public key-private key pair 414 associated with user device 402. In some embodiments, a specific timestamp may be generated and associated with the creation of each respective public key-private key pair.

[0071] At 520, processing circuitry 274 of server 212 may generate a digital signature 430 associated with vehicle 406. For example, processing circuitry 274 may implement digital signature generator 428 to generate digital signature 430 using vehicle identifier 424 and private key 413 associated with vehicle 406. In some embodiments, in generating digital signature 430, a cryptographic hash function may be utilized to generate a hash value of vehicle identifier 424, and such hash value of vehicle identifier 424 may be combined with private key 413 (e.g., encrypted by the private key) to generate digital signature 430. In some embodiments, a specific timestamp may be generated and associated with digital signature 430. In some embodiments, an EdDSA protocol (e.g., Ed25519 protocol) may be employed to generate digital signature 430.

[0072] At 522, processing circuitry 274 of server 212 may generate a digital signature 432 associated with user device 402. For example, processing circuitry 274 may implement digital signature generator 428 to generate digital signature 432 using mobile application identifier 426 and private key 417 associated with user device 402. In some embodiments, in generating digital signature 432, a cryptographic hash function may be utilized to generate a hash value of mobile application identifier 426, and such hash value of mobile application identifier 426 may be combined with private key 417 (e.g., encrypted by the private key) to generate digital signature 430. In some embodiments, a specific timestamp may be generated and associated with digital signature 432. In some embodiments, an EdDSA protocol (e.g., Ed25519 protocol) may be employed to generate digital signature 432.

[0073] At 524, processing circuitry 274 of server 212 may cause communication circuitry 280 to send digital signature 430 and public key 411 to vehicle 406 via network 210. In some embodiments, communication circuitry 280 may send vehicle identifier 424 to vehicle 406. In some embodiments, vehicle 406 may have previously received vehicle identifier 424, or it may be stored and / or embedded in processing circuitry 216 during manufacture of vehicle 406. At 526, digital signature 430 and public key 411 may be stored at memory module 220 of vehicle 206.

[0074] At 528, processing circuitry 274 of server 212 may cause communication circuitry 280 to send digital signature 432 and public key 415 to user device 402 via network 210. In some embodiments, communication circuitry 280 may send mobile application identifier 426 to user device 402. In some embodiments, user device 402 may have previously received mobile application identifier 426, or a mobile application implemented at user device 402 may store mobile application identifier 426, e.g., an identifier assigned once user 401 creates a user account with a mobile application. At 530, the mobile application executing on user device 402 may facilitate storing digital signature 432 and public key 415 in local memory 244 of user device 402.

[0075] Figure 6 A flowchart of an exemplary process for securely authenticating a user and allowing access to vehicle information based on a digital signature according to some embodiments of the present disclosure is shown. Process 600 may be performed at least in part by processing circuitry 274 of server 212 and / or processing circuitry 240 of user device 202 and / or processing circuitry 216 of vehicle 206.

[0076] At 614, the processing circuit 274 of the server 212 may receive a request to access the vehicle information. In some embodiments, when the user 401 selects option 433, the request may be received and the vehicle information may be stored at the distributed ledger 444. At 616, the user 401 may have logged in and authenticated, or may be prompted to enter his or her credentials for authentication. In some embodiments, user details, such as user ID, user device ID, vehicle ID, public key-private key pair, mobile application ID, etc., may be retrieved or obtained from the memory 278 by the processing circuit 274 of the server 212 for the authenticated user. In some embodiments, since the user 401 has previously been signed for secret management services, the server 212 may verify the identity of the user 401 on each of the server 212, the vehicle 206, and the mobile application implemented at the user 402.

[0077] At 618, processing circuitry 274 of server 212 may cause communication circuitry 280 to send a request to user device 402 to verify digital signature 432 associated with the user account of user 401. At 620, a mobile application implemented at user device 402 may perform a verification process in conjunction with digital signature 432. For example, to verify the identity of user 401, the mobile application may locally compute a hash value of mobile application identifier 426, and extract a hash value of digital signature 432 (e.g., by decrypting digital signature 432 using previously received public key 415), and compare the locally computed hash value with the hash value extracted from digital signature 432 to verify the identity of user 401. At 622, the mobile application may provide an indication to server 412 that digital signature 432 has been verified.

[0078] At 624, the processing circuitry 274 of the server 212 may cause the communication circuitry 280 to send a request to the vehicle 406 to verify the digital signature 430 associated with the user account of the user 401. At 626, the software implemented at the vehicle 406 may perform a verification process in conjunction with the digital signature 430. For example, to verify the identity of the user 401, the vehicle 406 may locally calculate a hash value of the vehicle identifier 424, and extract a hash value of the digital signature 430 (e.g., by decrypting the digital signature 430 using the previously received public key 411), and compare the locally calculated hash value with the hash value extracted from the digital signature 430 to verify the identity of the user 401. At 628, the mobile application may provide an indication to the server 412 that the digital signature 432 has been verified. In some embodiments, before performing the verification at 620 and 626 and / or providing the indication at 622 and 628, the vehicle 406 and / or the user device 402 may prompt the user 401 to confirm that he or she has requested the vehicle information as an additional layer of security.

[0079] At 630, in response to determining that user 401 has been authenticated at each of server 412, vehicle 406, and the mobile application implemented at user device 402 or user device 404, server 412 may access vehicle information stored at distributed ledger 444. In some embodiments, server 412 may locally store a copy of distributed ledger 444, which may be a public or private decentralized database in which any suitable number of nodes participate. In some embodiments, the vehicle information may be stored in JSON format or any other suitable format and may correspond to recent transactions associated with vehicle 406. In some embodiments, distributed ledger 444 may store smart contracts and / or NFTs.

[0080] At 632, the server 412 may obtain the vehicle information (e.g., requested by the user 401 at 614), which may be encrypted using any suitable technique. In some embodiments, the requested vehicle information may be returned to the requesting device, e.g., the vehicle 406, e.g., at 638, and / or the user device 402, e.g., at 634. At 636, the user device 402 may decrypt the received vehicle information and securely store it for any suitable period of time. At 640, the vehicle 406 may decrypt the received vehicle information and securely store it for any suitable period of time.

[0081] The foregoing merely illustrates the principles of the present disclosure, and various modifications may be made by those skilled in the art without departing from the scope of the present disclosure. The above embodiments are presented for the purpose of illustration and not limitation. The present disclosure may also take many forms other than those explicitly described herein. Therefore, it should be emphasized that the present disclosure is not limited to the methods, systems, and instruments explicitly disclosed, but is intended to include variations and modifications thereof, which are within the spirit of the following claims.

Claims

1. A method for securely managing vehicle information, the method comprising: generating, by a processor associated with the server, a first public key-private key pair and a second public key-private key pair; generating, by the processor and based on the first public key-private key pair and a vehicle identifier of the vehicle, a first digital signature associated with the vehicle; generating, by the processor and based on the second public key-private key pair and a mobile application identifier of a mobile application associated with a mobile device operated by a user, a second digital signature associated with the mobile application, wherein the vehicle identifier and the mobile application identifier are associated with a user profile in a database maintained by the server; sending, by the processor, the first digital signature and the public key of the first public key-private key pair to the vehicle, wherein the first digital signature is stored in a memory module associated with the vehicle; sending, by the processor, the second digital signature and the public key of the second public key-private key pair to the mobile application, wherein the mobile application facilitates storing the second digital signature in a local memory of the mobile device; determining that a request to access the vehicle information has been received, wherein the request is associated with the user profile; as well as Access to the vehicle information is permitted based on the first digital signature and the second digital signature.

2. The method according to claim 1, wherein: Allowing access to the vehicle information based on the first digital signature and the second digital signature includes: receiving, by the processor, a first indication that the vehicle has authenticated the vehicle identifier associated with the user profile, wherein the authentication associated with the first indication is performed using the first digital signature; receiving, by the processor, a second indication that the mobile application has authenticated the mobile application associated with the user profile, wherein the authentication associated with the second indication is performed using the second digital signature; and Access to the vehicle information is permitted by the processor in response to receiving the first indication and the second indication.

3. The method according to claim 1, further comprising: determining, by the processor, that a user associated with the user profile has selected an option for registering secure management of the vehicle information; as well as The first public key-private key pair and the second public key-private key pair are generated by the processor in response to determining that the user associated with the user profile has selected an option for registering for secure management of the vehicle information.

4. The method of claim 1, wherein the vehicle information is stored in a distributed ledger.

5. The method of claim 4, wherein at least one of the first public key-private key pair and the second public key-private key pair can be used to perform a transaction associated with the vehicle information on the distributed ledger and update the distributed ledger based on the transaction.

6. The method according to claim 4, wherein: The first digital signature is associated with a non-fungible token stored at the distributed ledger, wherein the non-fungible token includes historical ownership information of the vehicle and is transferable to a new vehicle owner. 7 . The method of claim 1 , wherein determining that the request to access the vehicle information has been received comprises receiving login credentials and determining whether the received login credentials match login credentials of the user profile. The method of claim 1 , wherein the mobile application is implemented at a key fob or a smart phone.

9. A system for securely managing vehicle information, the system comprising: A server, wherein the server is configured to: generating a first public key-private key pair and a second public key-private key pair; generating a first digital signature associated with the vehicle based on the first public key-private key pair and a vehicle identifier; generating a second digital signature associated with the mobile application based on the second public key-private key pair and a mobile application identifier of the mobile application associated with a mobile device operated by a user, wherein the vehicle identifier and the mobile application identifier are associated with a user profile in a database maintained by the server; sending the first digital signature and the public key of the first public key-private key pair to the vehicle, wherein the first digital signature is stored in a memory module associated with the vehicle; sending the second digital signature and the public key of the second public key-private key pair to the mobile application, wherein the mobile application facilitates storing the second digital signature in a local memory of the mobile device; a processing circuit, the processing circuit being configured to: determining that a request to access the vehicle information has been received, wherein the request is associated with the user profile; as well as Access to the vehicle information is permitted based on the first digital signature and the second digital signature.

10. The system of claim 9, wherein: The processing circuit is configured to allow access to the vehicle information based on the first digital signature and the second digital signature by: receiving a first indication that the vehicle has authenticated the vehicle identifier associated with the user profile, wherein the authentication associated with the first indication is performed using the first digital signature; receiving a second indication that the mobile application has authenticated the mobile application associated with the user profile, wherein the authentication associated with the second indication is performed using the second digital signature; and Access to the vehicle information is permitted in response to receiving the first indication and the second indication.

11. The system according to claim 9, wherein the server is further configured to: determining that a user associated with the user profile has selected an option for registering secure management of the vehicle information; and In response to determining that the user associated with the user profile has selected an option for registering for secure management of the vehicle information, the first public key-private key pair and the second public key-private key pair are generated.

12. The system of claim 9, wherein the vehicle information is stored at a distributed ledger.

13. The system of claim 12, wherein at least one of the first public key-private key pair and the second public key-private key pair is usable to perform a transaction associated with the vehicle information on the distributed ledger and update the distributed ledger based on the transaction.

14. The system of claim 12, wherein: The first digital signature is associated with a non-fungible token stored at the distributed ledger, wherein the non-fungible token includes historical ownership information of the vehicle and is transferable to a new vehicle owner. 15 . The system of claim 9 , wherein the server is configured to determine that the request to access the vehicle information has been received by receiving login credentials and determining whether the received login credentials match login credentials of the user profile.

16. The system of claim 9, wherein the mobile application is implemented at a key fob or a smart phone.

17. A non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor associated with a server, cause the processor to: generating a first public key-private key pair and a second public key-private key pair; generating a first digital signature associated with the vehicle based on the first public key-private key pair and a vehicle identifier of the vehicle; generating a second digital signature associated with the mobile application based on the second public key-private key pair and a mobile application identifier of the mobile application associated with a mobile device operated by a user, wherein the vehicle identifier and the mobile application identifier are associated with a user profile in a database maintained by the server; sending the first digital signature and the public key of the first public key-private key pair to the vehicle, wherein the first digital signature is stored in a memory module associated with the vehicle; sending the second digital signature and the public key of the second public key-private key pair to the mobile application, wherein the mobile application facilitates storing the second digital signature in a local memory of the mobile device; determining that a request to access the vehicle information has been received, wherein the request is associated with the user profile; as well as Access to the vehicle information is permitted based on the first digital signature and the second digital signature.

18. The non-transitory computer readable medium of claim 17, wherein: Executing the instructions to allow access to the vehicle information based on the first digital signature and the second digital signature further causes the processor to: receiving a first indication that the vehicle has authenticated the vehicle identifier associated with the user profile, wherein the authentication associated with the first indication is performed using the first digital signature; receiving a second indication that the mobile application has authenticated the mobile application associated with the user profile, wherein the authentication associated with the second indication is performed using the second digital signature; and Access to the vehicle information is permitted in response to receiving the first indication and the second indication.

19. The non-transitory computer readable medium of claim 17, wherein executing the instructions further causes the processor to: determining that a user associated with the user profile has selected an option for registering secure management of the vehicle information; and In response to determining that the user associated with the user profile has selected an option for registering for secure management of the vehicle information, the first public key-private key pair and the second public key-private key pair are generated.

20. The non-transitory computer readable medium of claim 17, wherein the vehicle information is stored at a distributed ledger.

Images