Method and device for managing verification of fod certificate on basis of blockchain

Abstract

A method and a device for managing verification of an FoD certificate on the basis of a blockchain are disclosed. According to an embodiment of the present disclosure, a method performed by a device for managing verification of an FoD certificate may comprise the steps of: generating a private key, a public key, and a blockchain-based address on the basis of a vehicle identification number (VIN) of a vehicle and personally identifying information (PII) of a driver; when the verification of the FoD certificate is completed, generating a data format on the basis of the verification of the FoD certificate; generating a transaction by using the data format and the private key; transmitting information of the transaction to a verification node; and when the verification node completes the verification of the transaction by using the public key, receiving verification result information of the transaction from the verification node, and generating blocks by using the verification result information of the transaction.

Description

Method and device for managing verification of FOD certificates based on blockchain

[0001] The present invention relates to a method and device for managing the verification of a Feature of Demand (FoD) certificate based on a blockchain. More specifically, the present invention relates to a method and device for managing the verification of a FoD certificate by creating a transaction using a FoD certificate and verifying the transaction using a verification node or query entity.

[0002] The content described below merely provides background information related to the present embodiment and does not constitute prior art.

[0003] FoD (Feature on Demand) is a subscription-based service that allows vehicle users to selectively download and install required features. FoD allows users to download and install features online or offline through a vehicle-connected system.

[0004] Previously, when purchasing a vehicle, the customer would select the features they would like to use and pre-install them in the vehicle before delivery. However, with the FoD service, customers can selectively purchase and add the features they want even after delivery.

[0005] For example, vehicle users can purchase specific features such as Adaptive Cruise Control (ACC), Autonomous Emergency Braking (AEB), Lane Support System (LSS), Around View Monitor (AVM), and Parking Assist System (PAS) from the manufacturer and then download and install those features remotely, regardless of time and location.

[0006] However, FoD services require users to communicate with the FoD server via their smartphone or vehicle's infotainment system when subscribing, and this process can expose users to various cyberattacks. For example, attackers could sniff or steal data transmitted and received between the vehicle and the FoD server, allowing them to use the feature in their own vehicle without paying the subscription fee. To ensure the safety of subscription services from these various cyberattacks, the application of cybersecurity technology is essential.

[0007] The purpose of this disclosure is to generate a private key, a public key, and an address based on a driver's PII (Personally Identifying Information) and a vehicle's VIN (Vehicle Identification Number).

[0008] Additionally, according to one embodiment, the purpose is to receive verification result information of a transaction from a verification node or query entity.

[0009] Additionally, according to one embodiment, the purpose is to generate blocks using verified transactions and to generate a blockchain using the blocks.

[0010] The problems to be solved by the present invention are not limited to the problems mentioned above, and other problems not mentioned will be clearly understood by those skilled in the art from the description below.

[0011] A method performed by a device for managing verification of a FoD certificate according to the present disclosure may include a process of generating a private key, a public key, and a blockchain-based address based on a VIN (Vehicle Identification Number) of a vehicle and a PII (Personally Identifying Information) of a driver, a process of generating a data format based on verification of the FoD certificate when verification of the FoD certificate is completed, a process of generating a transaction using the data format and the private key, a process of transmitting information of the transaction to a verification node, and a process of receiving verification result information of the transaction from the verification node when the verification node completes verification of the transaction using the public key, and a process of generating blocks using the verification result information of the transaction, wherein the information of the transaction may include an ID of the transaction, an encrypted data format, and original data.

[0012] According to the present disclosure, a method performed by a device for managing verification of a FoD certificate may include a process of generating a private key, a public key, and a blockchain-based address based on a VIN of a vehicle and a PII of a driver, a process of generating a data format based on verification of the FoD certificate when verification of the FoD certificate is completed, a process of generating a transaction using the data format and the private key, a process of receiving query information from a query entity and transmitting information of the transaction to the query entity based on the query information, and a process of receiving verification result information of the transaction from the query entity when the query entity completes verification of the transaction using the public key, and generating blocks using the verification result information of the transaction, wherein the information of the transaction may include an ID of the transaction, an encrypted data format, and original data.

[0013] According to the present disclosure, a device for managing verification of a FoD certificate includes a memory and a plurality of processors, wherein at least one processor among the plurality of processors generates a private key, a public key, and a blockchain-based address based on a VIN of a vehicle and a PII of a driver, generates a data format based on the verification of the FoD certificate when verification of the FoD certificate is completed, generates a transaction using the data format and the private key, transmits information of the transaction to a verification node, and when the verification node completes verification of the transaction using the public key, receives verification result information of the transaction from the verification node, and generates blocks using the verification result information of the transaction, and the information of the transaction may include an ID of the transaction, an encrypted data format, and original data.

[0014] According to the present disclosure, there is an effect of strengthening the uniqueness of private keys, public keys, and addresses and reducing the duplication of private keys, public keys, and addresses.

[0015] In addition, according to one embodiment, there is an effect of strengthening the integrity of the verification result of a FoD (Feature of Demand) certificate and ensuring the traceability of the FoD certificate.

[0016] Additionally, according to one embodiment, there is an effect that can prevent an attacker from manipulating the verification result of a FoD certificate.

[0017] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned will be clearly understood by a person having ordinary skill in the art to which the present disclosure pertains from the description below.

[0018] FIG. 1 is a diagram for explaining a process of using a functional subscription service according to one embodiment of the present disclosure.

[0019] FIG. 2 is a diagram for explaining a certificate-based FoD (Feature of Demand) service ecosystem using a public key structure according to one embodiment of the present disclosure.

[0020] FIG. 3 is a diagram illustrating a vehicle connected to a server via a network according to one embodiment of the present disclosure.

[0021] FIG. 4 is a block diagram illustrating a vehicle connected to an external network according to one embodiment of the present disclosure.

[0022] FIG. 5 is a block diagram illustrating a gateway according to one embodiment of the present disclosure.

[0023] FIG. 6 is a block diagram illustrating a server according to one embodiment of the present disclosure.

[0024] FIG. 7 is a block diagram illustrating a device for managing verification of FoD certificates based on blockchain according to one embodiment of the present disclosure.

[0025] FIG. 8A and FIG. 8B are diagrams illustrating a process in which a vehicle receives verification result information of a transaction from a verification node or query entity and generates blocks, according to one embodiment of the present disclosure.

[0026] FIG. 9 is a diagram illustrating a process of generating blocks using verification result information of a transaction received from a verification node according to one embodiment of the present disclosure.

[0027] FIG. 10 is a flowchart illustrating a process of generating blocks using verification result information of a transaction received from a query entity according to one embodiment of the present disclosure.

[0028] FIG. 11 is a block diagram schematically illustrating an exemplary computing device that can be used to implement a method according to the present disclosure.

[0029] Hereinafter, some embodiments of the present disclosure will be described in detail using exemplary drawings. When designating components in each drawing, it should be noted that, where possible, identical components are given the same reference numerals, even if they appear in different drawings. Furthermore, when describing the present disclosure, detailed descriptions of related known structures or functions will be omitted if they are deemed to obscure the gist of the present disclosure.

[0030] In describing components of embodiments according to the present disclosure, symbols such as first, second, i), ii), a), b) may be used. These symbols are only for distinguishing the components from other components, and the nature, order, or sequence of the components are not limited by the symbols. When a part in the specification is said to "include" or "have" a component, this does not mean that other components are excluded, but rather that other components may be included, unless explicitly stated otherwise.

[0031] The detailed description set forth below, together with the accompanying drawings, is intended to explain exemplary embodiments of the present disclosure and is not intended to represent the only embodiments in which the present disclosure may be practiced.

[0032] FIG. 1 is a diagram for explaining a process of using a functional subscription service according to one embodiment of the present disclosure.

[0033] Referring to FIG. 1, in the FoD (Feature of Demand) ecosystem, a driver (110) can subscribe to or cancel a necessary feature of a vehicle, and when a feature expires, the feature can no longer be used. If the driver (110) no longer needs the feature, the driver (110) can transfer the feature to another driver. The driver (110) checks a list of features available for subscription in the vehicle (120) and requests a subscription to a new feature using the driver's (110) Personally Identifying Information (PII), the vehicle identification number (VIN) of the vehicle (120), and payment information (1).

[0034] The vehicle (120) transmits subscription request data to the FoD server (130) to check for new functions (2).

[0035] The FoD server (130) verifies the driver's (110) PII, the vehicle identification number (120) and payment information (3).

[0036] The FoD server (130) installs new features into the vehicle (120) using OTA (Over The Air) updates (4).

[0037] The central control unit (CCU) of the vehicle (120) receives installation data for a new function and then verifies the format of the installation data using the Unified Diagnostic Services (UDS) protocol. Here, the UDS protocol is a standard protocol for vehicle diagnosis.

[0038] The central control unit of the vehicle (120) routes installation data to the electronic control device using the ID of the electronic control device (5).

[0039] The electronic control unit activates and operates new functions through this routing (6). For example, the electronic control unit can activate the Lane Support System (LSS) function.

[0040] Assets of a FoD service may include software, cryptographic data, communication data, personal information, and log data. Software is required to operate the FoD service. Cryptographic data includes public keys, private keys, certificates, passwords, seeds, and salts for encryption, decryption, and hash calculation. Communication data may include data between the vehicle, central control unit, electronic control unit, and FoD server for installing features in the vehicle. Personal information may include PII for driver and vehicle identification, vehicle identification number, payment information, and the driver's FoD service subscription list. Log data may include data regarding CCU / ECU status, feature ON / OFF events, and feature subscription timestamps.

[0041] In the FoD ecosystem, various security threats may exist, such as DDoS replay, attacker attacks, and impersonation against the assets of these FoD services.

[0042] For example, an attacker may exploit the payment information of the driver (110) when the driver (110) requests a subscription to a new feature in the vehicle (120). Accordingly, the driver (110) may subscribe to the feature requested by the attacker. The attacker may exploit the vehicle identification number (VIN) when the FoD server (130) installs a new feature in the vehicle (120) to prevent the installation. The attacker may eavesdrop on the feature installation data transmitted by the FoD server (130) to the vehicle (120) and exploit the feature installation data to subscribe to the feature without paying the subscription fee. The attacker may attack the FoD server (130) and the central control unit to manipulate the feature installation data, thereby causing a malfunction of the electronic control unit or triggering a function that the driver (110) does not want. An attacker can disrupt the installation by performing a DDoS attack on the FoD server (130), the central control unit, or the electronic control unit when the FoD server (130) installs a new feature in the vehicle (120).

[0043] There are various methods to prevent security attacks by these attackers.

[0044] The first method encrypts payment information, stores PII and vehicle identification numbers separately from other personal information, and destroys payment information that is no longer needed so that it cannot be recovered.

[0045] The second method is to use an encrypted VIN or a value that replaces the VIN in the FoD service.

[0046] The third method is to encrypt the function installation data using an encryption mechanism that uses a symmetric key or asymmetric key.

[0047] The fourth method is to maintain the integrity of the function installation data by using a digital signature or hash function.

[0048] The fifth method is to defend against DDoS attacks by using firewalls, traffic monitoring, etc.

[0049] FIG. 2 is a diagram for explaining a certificate-based FoD (Feature of Demand) service ecosystem using a public key structure according to one embodiment of the present disclosure.

[0050] Referring to FIG. 2, the integrity and confidentiality of the functional installation data transmitted by the FoD server (210) to the vehicle (220) are guaranteed based on a certificate using a public key infrastructure (PKI). The certificate-based FoD service ecosystem using a public key structure includes two major processes: certificate issuance and certificate use.

[0051] Certificate issuance

[0052] When a driver subscribes to a new feature, the vehicle (220) transmits subscription request data to the FoD server (210). The subscription request data may include information about the feature type, PII, vehicle identification number, and payment. The FoD server (210) receives the subscription request data, stores the feature type, and then transmits the subscription request data to a CA server (Certificate Authority server, 230). The CA server (230) verifies the subscription request data and issues a certificate. The fields of the certificate may include a version, a serial number, a tag, a vehicle identification number, an electronic control unit ID, a function flag, a challenge, an issuer, an order ID, an issuance date, an effective date, an expiration date, a reservation, and a signature.

[0053] The CA server (230) issues a certificate and then signs the certificate based on a digital signature technology using a private key. The CA server (230) encrypts the certificate using a symmetric key-based encryption mechanism. Here, the symmetric key can be safely distributed in advance. The CA server (230) transmits the encrypted data to the FoD server (210). The FoD server (210) searches for the ID of the corresponding electronic control device using the type of the pre-stored function and adds the ID of the corresponding electronic control device to the encrypted data. The FoD server (210) transmits the encrypted data with the ID of the corresponding electronic control device added to the vehicle (220). The central control unit of the vehicle (220) routes the encrypted data to the corresponding electronic control device using the ID of the corresponding electronic control device.

[0054] The electronic control unit may be composed of a host and an HSM (Hardware Security Module). The host receives encrypted data and transmits it to the HSM. The HSM decrypts the encrypted data using a pre-shared symmetric key and verifies the signature using the public key of the CA server (230). The HSM shares the verification result with the host. If the verification result is correct, the general fields such as the vehicle identification number, electronic control unit ID, and function flags are verified to be correct. If all fields are correct, the HSM re-verifies the signature, encrypts both the general fields and the signature using the pre-shared symmetric key, and stores the encrypted data in a storage. The electronic control unit signs the challenge field of the certificate and returns both the field and the signature to the CA server (230). The CA server (230) verifies the signature using the public key of the electronic control unit. Accordingly, mutual authentication between the CA server (230) and the electronic control unit is guaranteed.

[0055] Use of certificates

[0056] When the vehicle (220) is turned on, the central control unit of the vehicle (220) identifies the list of pre-installed functions and the ID of the corresponding electronic control unit. The electronic control unit obtains encrypted data from the storage and verifies the signature in the HSM. The host verifies general fields such as the vehicle identification number, function flag, and expiration date. If the verification result is correct, the electronic control unit activates the function.

[0057] FIG. 3 is a diagram illustrating a vehicle connected to a server via a network according to one embodiment of the present disclosure.

[0058] Referring to FIG. 3, a vehicle (310) may be connected to a server (320) that provides functions or services related to the vehicle (310) through a mobile network or wireless network such as LTE, 5G, or Wi-Fi.

[0059] FIG. 4 is a block diagram illustrating a vehicle connected to an external network according to one embodiment of the present disclosure.

[0060] Referring to FIG. 4, the vehicle (310) includes all or part of a gateway (410) connected to an external network and an internal network, and subsystems connected to the internal network. The vehicle (310) and each of its components may be implemented in hardware or software, or a combination of hardware and software. Furthermore, the functions of each component may be implemented in software, and one or more processors may be implemented to execute the functions of the software corresponding to each component.

[0061] The gateway (410) is a system that controls communication and has the function of safely transmitting data within the vehicle (310). The subsystems may include a power train subsystem, a body subsystem, a chassis subsystem, an infotainment subsystem, etc. A subsystem includes one or more components that perform similar functions and are connected by the same type of internal bus. Each component is controlled and driven by one or more ECUs (420).

[0062] The powertrain subsystem is a collection of components that generate the driving force of the vehicle (310). The powertrain subsystem may include components such as an engine, motor, transmission, battery, and generator. The body subsystem is a collection of components that enhance driver convenience and safety. The body subsystem may include components such as seats, heating / ventilation / air conditioning, lighting, doors, and windows. The chassis subsystem is a collection of components necessary for driving the vehicle (310). The chassis subsystem may include components related to steering, brakes, and tires. The infotainment subsystem is a collection of components related to driving guidance or multimedia of the vehicle (310). The infotainment subsystem may include components such as a navigation system, a multimedia system, and a head-up display.

[0063] The internal network connecting the gateway (410) and the components constituting the subsystems may be a communication protocol such as LIN (Local Interconnect Network), CAN (Control Area Network), CAN-FD, FlexRay, MOST (Media Oriented Systems Transport), Ethernet, etc. The components within the subsystems transmit and receive data to each other through the gateway (410). The gateway (410) may transmit an encrypted vehicle identification number received from the server (320) to one or more ECUs (420). The gateway (410) may transmit vehicle identification number reception confirmation data received from one or more ECUs (420) to the server (320).

[0064] FIG. 5 is a block diagram illustrating a gateway according to one embodiment of the present disclosure.

[0065] Referring to FIG. 5, the gateway (410) may include all or part of a central control unit (510), a communication unit (520), an ECU list storage unit (530), and a storage unit (540). The gateway (410) and each of its components may be implemented in hardware or software, or a combination of hardware and software. In addition, the functions of each component may be implemented in software, and one or more processors may be implemented to execute the functions of the software corresponding to each component.

[0066] The central control unit (510) controls the overall operation of the vehicle (310). The central control unit (510) can control the operation of the vehicle (310) by controlling the electronic control device included in at least one subsystem according to the driver's request, driving conditions, etc. The functions performed by the central control unit (510) may include driving management, parking management, remote diagnosis, remote control, FoD management, software update, and security management. FoD management is a type of subscription service management, such as downloading and activating a new function from a server or activating a deactivated function. The central control unit (510) performs the setup or cancellation of the subscription service. The central control unit (510) can check whether the activated function is a function selected by the customer or whether the activation of the function is due to an illegal method, and can activate or deactivate the function based on the results.

[0067] Software update is a service performed by the central control unit (510) when software update conditions are met in a vehicle to which OTA is applied. Software update may include updating the software that manages the overall operation of the vehicle as well as the firmware installed in the electronic control unit of each component.

[0068] Security management may include functions or services related to vehicle security or the authentication of external devices accessing the in-vehicle network. Security threats related to vehicles may include firmware tampering, remote control hacking, CAN tampering, illegal vehicle operation, and denial of service. Security threats related to external networks may also include communication eavesdropping and message tampering. Security management may include functions for detecting and responding to intrusions into the vehicle's internal network via external networks (Intrusion Detection System (IDS)) and services for recording data related to security events (Event Data Recorder (EDR).

[0069] The communication unit (520) transmits and receives data with the server (320) through an external network, and transmits and receives data with the subsystem components and electronic control devices through an internal network.

[0070] The ECU list storage unit (530) stores a list of ECUs and determines an electronic control device matching the ID of the electronic control device within the list of ECUs.

[0071] The storage unit (540) stores data received from an external network and an internal network or data related to the operation of the vehicle (310).

[0072] FIG. 6 is a block diagram illustrating a server according to one embodiment of the present disclosure.

[0073] Referring to FIG. 6, the server (320) may include all or part of a management unit (610), a communication unit (620), a storage unit (630), and an encryption unit (640). The server (320) and each of its components may be implemented in hardware or software, or a combination of hardware and software. In addition, the functions of each component may be implemented in software, and one or more processors may be implemented to execute the functions of the software corresponding to each component. The server (320) may be a general back-end server capable of communicating with the vehicle (310).

[0074] The management unit (610) manages operations according to the request of the vehicle (310). For example, the management unit (610) can manage operations such as software updates, transmission of data related to FoD, and security / authentication of the vehicle.

[0075] The communication unit (620) connects to the vehicle (310) through an external network and transmits and receives data.

[0076] The storage unit (630) stores data related to driving of the vehicle (310) and manages the version of software installed in each vehicle, activated functions, and authentication-related information.

[0077] The encryption unit (640) manages a symmetric key and a key for electronic signatures, and encrypts the vehicle identification number using the symmetric key. The encryption unit (640) generates data composed of parameters including the encrypted vehicle identification number. The encryption unit (640) verifies the values ​​obtained by electronically signing the parameters, hashes the vehicle identification number, and generates and stores the hashed vehicle identification number.

[0078] FIG. 7 is a block diagram illustrating a device for managing verification of FoD certificates based on blockchain according to one embodiment of the present disclosure.

[0079] Referring to FIG. 7, a device for managing verification of a FoD certificate based on a blockchain (hereinafter, referred to as a verification management device, 70) may include all or part of a transaction generation unit (710), a verification result reception unit (720), and a block generation unit (730). The verification management device (70) and each component thereof may be implemented as hardware or software, or may be implemented as a combination of hardware and software. In addition, the functions of each component may be implemented as software, and one or more processors may be implemented to execute the functions of the software corresponding to each component. The verification management device (70) may be a device included in the electronic control device (410) or a device mounted in a vehicle separately from the electronic control device (410).

[0080] The transaction generation unit (710) uses the driver's PII and the vehicle's VIN to generate a private key, public key, and address for the blockchain. The public key can be generated from the private key using the Elliptic Curve Digital Signature Algorithm (ECDSA), for example. ECDSA is a digital signature algorithm based on Elliptic Curve Cryptography. The address is the vehicle's address based on the blockchain and can be generated by applying a hash function to the public key. Accordingly, the private key, public key, and address may all be associated with the driver's PII and the vehicle's VIN.

[0081] To activate a specific FoD function, the vehicle receives a FoD certificate related to the FoD function from the FoD server and verifies the FoD certificate. When the verification of the FoD certificate is completed, the transaction generation unit (710) generates a data format based on the verification of the FoD certificate. Here, the data format may include information about a verification completion Unix timestamp, a verification completion flag, and the FoD certificate. Information about the FoD certificate may include information about the certificate version, the certificate serial number, the vehicle identification number, a function on / off flag, an order number, and an expiration date. The transaction generation unit (710) hashes the data format to generate a transaction ID, and encrypts the data format using a private key to generate an encrypted data format. The transaction generation unit (710) generates one transaction using the transaction ID, the encrypted data format, and the original data.

[0082] The verification result receiving unit (720) receives transaction verification result information from a verification node or query entity and determines whether the transaction has been verified. The block generation unit (730) creates blocks using verified transactions. The block generation unit (730) creates a blockchain using the created blocks. The created blocks can be used to create a new blockchain or can be chained to an existing blockchain. Blockchains based on other networks can also have blocks created by the block generation unit (730).

[0083] FIG. 8A and FIG. 8B are diagrams illustrating a process in which a vehicle receives verification result information of a transaction from a verification node or query entity and generates blocks, according to one embodiment of the present disclosure.

[0084] Referring to FIG. 8A, a vehicle (810) generates a transaction when verification of a FoD certificate is completed (1). The vehicle (810) transmits transaction information to a verification node (820) (2). Transaction information may include a transaction ID, an encrypted data format, and original data. The verification node (820) may be another vehicle, infrastructure, or a sub. The verification node (820) verifies the transaction using the transaction information (3). The verification node (820) decrypts the encrypted data format using the public key of the vehicle (810) and compares the decrypted data with the original data to verify the transaction. If the decrypted data and the original data are identical, the verification node (820) may determine that the transaction is verified. If the decrypted data and the original data are not identical, the verification node (820) may determine that the transaction is not verified.

[0085] The verification node (820) transmits the transaction verification result information to the vehicle (810) (4). If the transaction is determined to be unverified, the verification node (820) may not transmit the transaction verification result information to the vehicle (810). The vehicle (810) generates blocks using the transaction verification result information (5). The vehicle (810) may generate blocks using transactions that have no abnormalities in the verification result.

[0086] Referring to FIG. 8B, the vehicle (810) generates a transaction when the verification of the FoD certificate is completed (1). The query entity (830) transmits query information to the vehicle (810) (2). The query entity (830) may be a vehicle, infrastructure, a server, an investigation agency, an analysis period, a research institute, etc. The query information is information requesting transaction information, and may be a transaction ID and a vehicle address based on a blockchain. The vehicle (810) transmits the transaction information to the query entity (830) (3). If the query information is a transaction ID, the vehicle (810) may transmit information on one transaction for this transaction ID to the query entity (830). If the query information is a vehicle address based on a blockchain, the vehicle (810) may transmit information on all transactions generated from this address to the query entity (830).

[0087] The query entity (830) verifies the transaction using transaction information (4). The query entity (830) can decrypt the encrypted data format using the vehicle's (810) public key and compare the decrypted data with the original data to verify the transaction. If the decrypted data and the original data are identical, the query entity (830) can determine that the transaction has been verified. If the decrypted data and the original data are not identical, the query entity (830) can determine that the transaction has not been verified. Accordingly, the integrity of the transaction can be guaranteed.

[0088] The query entity (830) transmits the transaction verification result information to the vehicle (810) (5). If the transaction is determined to be unverified, the query entity (830) may not transmit the transaction verification result information to the vehicle (810). The vehicle (810) generates blocks using the transaction verification result information (6). The vehicle (810) may generate blocks using transactions that have no abnormalities in the verification result.

[0089] FIG. 9 is a diagram illustrating a process of generating blocks using verification result information of a transaction received from a verification node according to one embodiment of the present disclosure.

[0090] Referring to FIG. 9, the transaction generation unit (710) generates a private key, a public key, and a blockchain-based address based on the vehicle's VIN and the driver's PII (S910). When the verification of the FoD certificate is complete, the transaction generation unit (710) generates a data format based on the verification of the FoD certificate (S920). The transaction generation unit (710) generates a transaction using the data format and the private key (S930). The process of generating a transaction may include a process of hashing the data format to generate a transaction ID and a process of encrypting the data format using the private key to generate an encrypted data format.

[0091] The transaction generation unit (710) transmits transaction information to the verification node (820) (S940). If the verification node (820) completes transaction verification using the public key, the verification result receiving unit (720) receives the transaction verification result information from the verification node (820), and the block generation unit (730) generates blocks using the transaction verification result information (S950). The transaction information may include the transaction ID, encrypted data format, and original data.

[0092] The data format may include information about the validation completion Unix timestamp, the validation completion flag, and information about the FoD certificate. Information about the FoD certificate may include information about the certificate version, the certificate serial number, the VIN, the function on / off flag, the order number, and the expiration date.

[0093] FIG. 10 is a flowchart illustrating a process of generating blocks using verification result information of a transaction received from a query entity according to one embodiment of the present disclosure.

[0094] Referring to FIG. 10, the transaction generation unit (710) generates a private key, a public key, and a blockchain-based address based on the vehicle's VIN and the driver's PII (S1010). When the verification of the FoD certificate is complete, the transaction generation unit (710) generates a data format based on the verification of the FoD certificate (S1020). The transaction generation unit (710) generates a transaction using the data format and the private key (S1030). The process of generating a transaction may include a process of hashing the data format to generate a transaction ID and a process of encrypting the data format using the private key to generate an encrypted data format.

[0095] The transaction generation unit (710) receives query information from the query entity (830) and transmits transaction information to the query entity (830) based on the query information (S1040). The process of transmitting transaction information to the query entity (830) may include a process of transmitting transaction information using the transaction ID when the query information includes a transaction ID, and a process of transmitting information on all transactions generated based on the blockchain-based address when the query information includes a blockchain-based address.

[0096] When the query entity (830) completes transaction verification using a public key, the verification result receiving unit (720) receives transaction verification result information from the query entity (830), and the block generating unit (730) generates blocks using the transaction verification result information (S1050). The transaction information may include the transaction ID, encrypted data format, and original data.

[0097] The data format may include information about the validation completion Unix timestamp, the validation completion flag, and information about the FoD certificate. Information about the FoD certificate may include information about the certificate version, the certificate serial number, the VIN, the function on / off flag, the order number, and the expiration date.

[0098] FIG. 11 is a block diagram schematically illustrating an exemplary computing device that can be used to implement a method according to the present disclosure.

[0099] The computing device (1100) may include some or all of a memory (1110), a processor (1120), storage (1140), an input / output interface (1160), and a communication interface (1180). The computing device (1100) may structurally and / or functionally include at least a portion of a verification management device (70). The computing device (1100) may be a stationary computing device such as a desktop computer, a server, an AI accelerator, etc., as well as a portable computing device such as a laptop computer, a smart phone, etc.

[0100] The memory (1110) may store a program that causes the processor (1120) to perform a method or operation according to various embodiments of the present disclosure. For example, the program may include a plurality of instructions executable by the processor (1120), and the methods illustrated in FIGS. 9 and 10 may be performed by executing the plurality of instructions by the processor (1120).

[0101] Memory (1110) may be a single memory or multiple memories. In this case, information required to perform methods or operations according to various embodiments of the present disclosure may be stored in a single memory or divided and stored across multiple memories. If memory (1110) is comprised of multiple memories, the multiple memories may be physically separated.

[0102] The memory (1110) may include at least one of volatile memory and non-volatile memory. The volatile memory includes SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory), and the non-volatile memory includes flash memory.

[0103] The processor (1120) may include at least one core capable of executing at least one instruction. The processor (1120) may execute instructions stored in the memory (1110). The processor (1120) may be a single processor or multiple processors.

[0104] Storage (1140) maintains stored data even when power supplied to the computing device (1100) is cut off. For example, storage (1140) may include non-volatile memory or a storage medium such as magnetic tape, optical disk, or magnetic disk.

[0105] A program stored in storage (1140) may be loaded into memory (1110) before being executed by processor (1120). Storage (1140) may store a file written in a programming language, and a program generated from the file by a compiler or the like may be loaded into memory (1110). Storage (1140) may store data to be processed by processor (1120) and / or data processed by processor (1120).

[0106] The input / output interface (1160) may include an input device such as a keyboard, a mouse, etc., and a display device such as a display device, a printer, etc. A user may trigger the execution of a program by the processor (1120) and / or check the processing result of the processor (1120) through the input / output interface.

[0107] The communication interface (1180) may provide access to an external network. For example, the computing device (1100) may communicate with other devices via the communication interface (1180).

[0108] Each component of the device or method according to the present invention may be implemented in hardware, software, or a combination of hardware and software. Furthermore, the functions of each component may be implemented in software, with a microprocessor executing the software functions corresponding to each component.

[0109] Various implementations of the systems and techniques described herein may be implemented as digital electronic circuits, integrated circuits, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations of one or more computer programs executable on a programmable system. The programmable system includes at least one programmable processor (which may be a special purpose processor or a general purpose processor) coupled to receive data and instructions from and transmit data and instructions to a storage system, at least one input device, and at least one output device. Computer programs (also known as programs, software, software applications, or code) include instructions for the programmable processor and are stored on a "computer-readable recording medium."

[0110] A computer-readable recording medium includes any type of recording device that stores data that can be read by a computer system. Such a computer-readable recording medium may be a non-volatile or non-transitory medium such as a ROM, CD-ROM, magnetic tape, floppy disk, memory card, hard disk, magneto-optical disk, storage device, and may further include a transitory medium such as a data transmission medium. Furthermore, the computer-readable recording medium may be distributed across network-connected computer systems, so that computer-readable code can be stored and executed in a distributed manner.

[0111] Although the flowchart of this specification describes each process as being executed sequentially, this is merely an illustrative description of the technical idea of ​​one embodiment of the present disclosure. In other words, a person of ordinary skill in the art to which one embodiment of the present disclosure belongs can modify and apply various modifications and variations by changing the order described in the flowchart without departing from the essential characteristics of one embodiment of the present disclosure, or by executing one or more of the processes in parallel. Therefore, the flowchart is not limited to a chronological order.

[0112] The above description is merely an example of the technical idea of ​​the present embodiment, and those skilled in the art will appreciate that various modifications and variations can be made without departing from the essential characteristics of the present embodiment. Therefore, the present embodiments are not intended to limit the technical idea of ​​the present embodiment, but rather to explain it, and the scope of the technical idea of ​​the present embodiment is not limited by these embodiments. The scope of protection of the present embodiment should be interpreted by the claims below, and all technical ideas within a scope equivalent thereto should be interpreted as being included in the scope of rights of the present embodiment.

[0113]

[0114] CROSS-REFERENCE TO RELATED APPLICATION

[0115] This patent application claims priority to Korean Patent Application No. 10-2024-0050893, filed on April 16, 2024, the entire contents of which are incorporated herein by reference.

Claims

1. In a method performed by a verification management device, The process of generating private keys, public keys, and blockchain-based addresses based on the vehicle's VIN (Vehicle Identification Number) and the driver's PII (Personally Identifying Information); When the verification of the FoD certificate is completed, a process of creating a data format based on the verification of the FoD certificate; A process of creating a transaction using the above data format and the above private key; The process of transmitting the information of the above transaction to the verification node; and When the verification node completes verification of the transaction using the public key, a process of receiving verification result information of the transaction from the verification node and generating blocks using the verification result information of the transaction is included. A method in which the information of the above transaction includes the ID of the above transaction, the encrypted data format, and the original data.

2. In paragraph 1, A method wherein the above data format includes information about a verification completion Unix timestamp, information about a verification completion flag, and information about the FoD certificate.

3. In paragraph 2, A method in which information about the above FoD certificate includes information about the version of the certificate, information about the serial number of the certificate, information about the VIN, information about the function on / off flag, information about the order number, and information about the expiration date.

4. In paragraph 1, The process of creating the above transaction is: A process of generating an ID of the transaction by hashing the above data format; and A method comprising a process of encrypting the data format using the private key to generate the encrypted data format.

5. In a method performed by a verification management device, The process of generating private keys, public keys, and blockchain-based addresses based on the vehicle's VIN and the driver's PII; When the verification of the FoD certificate is completed, a process of creating a data format based on the verification of the FoD certificate; A process of creating a transaction using the above data format and the above private key; A process of receiving query information from a query entity and transmitting information of the transaction to the query entity based on the query information; and When the query entity completes verification of the transaction using the public key, a process of receiving verification result information of the transaction from the query entity and generating blocks using the verification result information of the transaction is included. A method in which the information of the above transaction includes the ID of the above transaction, the encrypted data format, and the original data.

6. In paragraph 5, A method wherein the above data format includes information about a verification completion Unix timestamp, information about a verification completion flag, and information about the FoD certificate.

7. In paragraph 6, A method in which information about the above FoD certificate includes information about the version of the certificate, information about the serial number of the certificate, information about the VIN, information about the function on / off flag, information about the order number, and information about the expiration date.

8. In paragraph 5, The process of creating the above transaction is: A process of generating an ID of the transaction by hashing the above data format; and A method comprising a process of encrypting the data format using the private key to generate the encrypted data format.

9. In paragraph 5, The process of transmitting the information of the above transaction to the above query entity is: If the above query information includes the ID of the transaction, a process of transmitting information of the transaction using the ID of the transaction; and A method comprising a process of transmitting information on all transactions generated based on an address based on the blockchain, when the query information includes an address based on the blockchain.

10. Memory; and In a verification management device including multiple processors, At least one processor among the plurality of processors, Generate private keys, public keys, and blockchain-based addresses based on the vehicle's VIN and the driver's PII. When the verification of the FoD certificate is completed, a data format is created based on the verification of the FoD certificate, Create a transaction using the above data format and the above private key, Transmit the information of the above transaction to the verification node, When the verification node completes verification of the transaction using the public key, the verification result information of the transaction is received from the verification node, and blocks are created using the verification result information of the transaction. A verification management device, wherein the information of the above transaction includes the ID of the above transaction, the encrypted data format, and the original data.

Images