Request processing system

Abstract

A request processing system is provided for receiving and executing a request transmitted from a first device by a second device, the first device having a unit for writing first device identification inherent data to a prescribed address on a communication network, and a request transmitting unit for transmitting a signed request signed with a secret key and the public key to the second device, the second device having a unit for reading the first device identification inherent data, generating public key data capable of uniquely identifying the public key based on the received public key, determining whether the downloaded first device identification inherent data contains the public key data, and based on the determination, authenticating the first device by verifying the signature of the signed request based on the public key received from the first device and the unlock password data contained in the downloaded first device identification inherent data, and a unit for executing the verified request based on the authentication of the first device.

Description

Technical Field

[0001] This invention relates to a request processing system and method for processing requests to lock and unlock vehicles, houses, lockers, etc. using electronic devices such as smart keys. Background Technology

[0002] The practical application of smart key systems that lock or unlock doors of vehicles, lockers, etc. without using physical keys has been developed. As existing technologies, the following are some examples.

[0003] Patent Document 1: Japanese Patent Application Publication No. 2006-9333

[0004] Patent Document 2: Japanese Patent Application Publication No. 2009-275363 Summary of the Invention

[0005] According to statistics, the average age of cars in Japan in 2017 was 12.91 years. In contrast, smart keys for locking and unlocking vehicles are typically managed by specific private companies, making it impossible to guarantee continuous management services throughout the vehicle's lifespan. Furthermore, the high management costs of these smart keys can be a significant burden, hindering sustained service.

[0006] The present invention was made in view of this situation, and its object is to provide a system in which a request processing device that processes requests between a smart key and an in-vehicle device can provide services more generally without relying on a specific service provider.

[0007] In order to achieve the above objectives, the inventors of the present invention, considering that when using the technology of authenticating the first device and the second device using a public key, the area stored in the storage area would be compressed if the actual public key is stored on the server, considered a device that can perform accurate authentication even if the public key is not shared on the network, and completed the present invention after careful verification.

[0008] That is, according to the first main point of the invention, the following invention is provided.

[0009] (1) A request processing system, comprising a first device and a second device associated with the first device.

[0010] Used to receive and execute requests sent from the first device using the second device, wherein,

[0011] The first device has:

[0012] A unit that stores the proprietary private and public keys;

[0013] A unit that generates inherent data for the first device identification, including public key data that can uniquely identify the public key and is smaller than the public key, and unlocking password data that can uniquely identify the unlocking password information;

[0014] The generated first device identifies the unit that writes inherent data to a specified address on the communication network; and

[0015] The signed request, using the key and the public key, is sent to the request sending unit of the second device.

[0016] The second device has:

[0017] The first device, whose data is written to the specified address, identifies the unit that reads out the inherent data.

[0018] A public key data uniquely identifying the public key is generated based on the public key received from the first device; it is determined whether the downloaded first device identification inherent data contains the public key data; and based on this determination, the unit of the first device is authenticated by verifying the signature of the signed request based on the public key received from the first device and the unlocking password data contained in the downloaded first device identification inherent data; and

[0019] A unit that executes the verification completion request based on the authentication of the first device.

[0020] According to this structure, when a request is sent from the first device to the second device, the public key is sent along with the request to the second device. Furthermore, the second device generates a small public key data set that uniquely identifies the aforementioned public key, compares it with proprietary data retrieved from a specified address on the network, and verifies the requested signature using specific unlocking data, thereby authenticating the user terminal.

[0021] Accordingly, the actual public key can be sent directly from the first device to the second device. Therefore, the shared information does not need to be the public key itself; only "public key data" smaller than the public key needs to be placed at a designated address on the network. This achieves the effect of not compressing the storage area of ​​the server managing smart keys, etc.

[0022] Here, according to one embodiment of the present invention, preferably, the first device is a smart key, and the second device is an on-board device mounted on the vehicle and controlling the unlocking and locking of the vehicle according to the request of the first device.

[0023] In another embodiment of the present invention, preferably, the public key data is a hash value generated by transforming the public key using a hash function, more preferably, the last 20 bytes of the hash value are the public key address used in the blockchain system.

[0024] According to another embodiment of the present invention, preferably, the first device identifies the address of the smart contract written to Ethereum with inherent data. Accordingly, if the inherent identification code of the user terminal is stored on the blockchain network, the universality of code storage can be ensured.

[0025] According to another embodiment of the present invention, preferably, the system sends information determining the first device to the address specified above in order to authenticate the write permission of the first device.

[0026] Furthermore, those skilled in the art will be able to understand features of the invention beyond the above description by referring to the following description of embodiments of the invention and the accompanying drawings. Attached Figure Description

[0027] Figure 1 This is an overall structural diagram of a system according to one embodiment of the present invention.

[0028] Figure 2 This is also a system architecture diagram representing a smart key.

[0029] Figure 3 It is also a schematic diagram showing the structure of the vehicle-mounted device.

[0030] Figure 4 This is also a schematic diagram showing the control unit of an onboard device.

[0031] Figure 5 This is also a system architecture diagram representing the smart key management server.

[0032] Figure 6 This is also a flowchart representing the process of setting up a smart contract address.

[0033] Figure 7 This is also a flowchart representing the issuance process of the user terminal's inherent identification code.

[0034] Figure 8 This is also a schematic diagram representing the user interface of a smart key.

[0035] Figure 9 This is also an explanatory diagram used to illustrate the structure of the inherent identification code of a user terminal.

[0036] Figure 10 This is also a flowchart representing the process of sending a request.

[0037] Figure 11 This is also a flowchart representing the request processing steps. Detailed Implementation

[0038] Hereinafter, one embodiment of the present invention will be described with reference to the accompanying drawings.

[0039] Figure 1 This is an overall structural diagram illustrating an example of applying the request processing system of the present invention to a smart key system 1 for locking and unlocking vehicle doors.

[0040] (Overall structure)

[0041] The smart key system 1 includes: one or more user terminals 2 (corresponding to the "first device" of the present invention); a smart contract 4 (the "specified address on the network" of the present invention) which is connected to the user terminal 2 via the Internet 3 (corresponding to the "network" of the present invention); an in-vehicle device 5 (corresponding to the "second device" of the present invention) which is mounted on a vehicle; and a smart key management server 6 which is used to manage the smart key system 1.

[0042] In this smart key system 1, the user terminal 2 pre-writes its unique identification code (unique data for identification by the first device) 7 into the smart contract 4 (A). On the other hand, the vehicle-mounted device 5 pre-retrieves the unique identification code 7 (B) from the smart contract 4 and stores it in the user terminal 2. Furthermore, when a vehicle user sends a specific request (C) to the vehicle-mounted device 5 using their stored user terminal 2, the vehicle-mounted device 5 is configured to authenticate the user terminal 2 using the unique identification code 7.

[0043] (Smart Contracts)

[0044] Here, the smart contract 4 is a computer protocol built on Ethereum, with the following structure: if the contract and its performance conditions are programmed in advance, the transaction will be automatically executed when the contract conditions are met.

[0045] Ethereum is structured such that the execution history of smart contracts is recorded in a blockchain on a peer-to-peer network called Ethereum / network. Ethereum has a customizable programming language for describing smart contracts, allowing network participants to describe and execute any smart contract on the blockchain. This structure eliminates reliance on a specific central governing body, enabling the entire peer-to-peer network to share program execution and its results as an execution environment.

[0046] (User terminal)

[0047] The user terminal 2 is typically a smartphone, but can also be a tablet computer or other computer device.

[0048] Furthermore, in this embodiment, three types of users using the user terminal 2 are defined: vehicle owners, their family members, and vehicle-sharing users. For example, in a vehicle-sharing service, the person engaged in the vehicle-sharing business is the vehicle owner, and the person sharing the vehicle is the vehicle-sharing user who only uses the vehicle. Similarly, in the case of a privately owned vehicle, the person engaged in the rental business is the vehicle owner, and the person renting the vehicle is the vehicle-sharing user who uses the vehicle. Additionally, in the case of a privately owned vehicle, the vehicle is registered in the name of the owner, and the family member driving the vehicle is the user who uses the vehicle.

[0049] In this implementation, as will be explained in detail later, the write permissions for smart contract 4 vary depending on the user type.

[0050] (Vehicle-mounted device)

[0051] The vehicle-mounted device 5 is an electronic device installed in the vehicle, which has the function of controlling the locking or unlocking of the vehicle doors. In addition to the above functions, the vehicle-mounted device 5 may also have other functions, such as highway toll payment function, navigation / audio / video function, etc.

[0052] In this embodiment, each vehicle-mounted device 5 is assigned a unique address (smart contract address) of a smart contract 4, and the user terminal 2 writes the aforementioned user terminal unique identification code 7 into this smart contract address. Figure 1 As shown in A). Furthermore, the aforementioned vehicle-mounted device 5 calls and saves the written user terminal-specific identification code 7 ( Figure 1 (As shown in B). Furthermore, upon receiving a signed request and public key from the user terminal 2 ( Figure 1 As shown in C), the user terminal identification is compared with the published individual code 7, and the signature of the signed request (unlock, lock) is verified to authenticate the user terminal 2, and then the request is processed appropriately.

[0053] (Smart Key Management Server)

[0054] In addition, the smart key management server 6, for example, is operated and managed by the applicant, and has the function of generating a smart contract 4 for each vehicle device on the blockchain, and has the function of setting the address of the smart contract to the user terminal 2 and the vehicle device 5.

[0055] The structure of each device 2 to 6 will be described in detail below.

[0056] (Detailed structure of the user terminal)

[0057] Figure 2 This is a schematic diagram representing the structure of user terminal 2.

[0058] User terminal 2 is configured such that data storage unit 14 and program storage unit 15 are connected to bus 13, which is connected to CPU 10, RAM 11, and input / output unit 12. In this embodiment, request input device 16, such as a button, keyboard, or touch screen, for inputting requests to the vehicle device 5, network communication device 17 for communicating with network 3, and vehicle device wireless communication device 18 are connected to input / output unit 12.

[0059] (Data Storage Department)

[0060] If only the data related to this invention is listed, the user's private key and public key 20, user ID 21 (Ethereum address in this embodiment), user type 22 (car owner, family member, sharer), user key attributes 23 (key validity period, etc.), unlock password information 24, user terminal unique identification code 7, request command information 26 (unlock, lock, etc.), and smart contract address 27 (Ethereum address) are stored in the data storage unit 14.

[0061] (Program Storage Department)

[0062] Furthermore, if only the structures related to the present invention are listed, the user key / public key generation unit 28, the user authentication unit 29, the public key address generation unit 30, the user terminal unique identification code generation unit 31, the unique identification code sending unit 32, the request acceptance unit 33, the signed request generation unit 34, and the signed request / public key sending unit 35 are stored in the program storage unit 15.

[0063] Furthermore, specifically, the data storage unit 14 and the program storage unit 15 are auxiliary storage devices (HDD, SDD) of the user terminal 2. Additionally, the functional units 29-35 stored in the program storage unit 15 are configured such that some or all of them are installed in the "smart key application 19" of the user terminal 2 (see reference). Figure 1 In addition, when installing the application 19, space is ensured in the auxiliary storage device of the user terminal 2 for storing the information 20 to 27 of the data storage unit 14.

[0064] Furthermore, the information 20-27 in the data storage unit 14 can be tables in a database and the values ​​stored in those tables, or they can be directly written as programs into the functional units 29-35 stored in the program storage unit 15. Additionally, since it is necessary to manage user keys in the most secure way possible, it is preferable to store them in advance in a security component provided by the user terminal (smartphone, etc.).

[0065] Furthermore, the functional units 29 to 35 stored in the program storage unit 15 are appropriately called, expanded, and executed on the RAM 11 by the CPU 10, thereby functioning as the structural elements described in the technical solution of this application.

[0066] (Vehicle-mounted device)

[0067] Figure 3 This is a schematic diagram showing the structure of the vehicle-mounted device 5.

[0068] The vehicle-mounted device 5 includes: a control unit 41; a transceiver unit 42 connected to the control unit 41; an operation unit 43; a display unit 44; and a voice output unit 45. The transceiver unit 42 is provided with an antenna 40 for direct wireless communication with the user terminal 2, and can connect to the Internet 3 for communication with the smart contract 4 and the smart key management server 6.

[0069] Figure 4 This is a functional block diagram showing the structure installed in the control unit 41.

[0070] The control unit 41 includes a user terminal unique identification code receiving unit 47, a signed request / public key receiving unit 48, a public key address generation unit 49, a user terminal authentication unit 50, and a request processing unit 51. Furthermore, the control unit 41 can store the smart contract address 27 and the user terminal unique identification code 7 in a memory.

[0071] (Smart Key Management Server)

[0072] in addition, Figure 5 This is a simplified functional block diagram representing the smart key management server 6.

[0073] If only the structures related to the present invention are shown, the smart key management server 6 has a vehicle / vehicle device management unit 53, a smart contract issuance unit 54, a smart contract address storage unit 55, and a user ID receiving unit 56.

[0074] The above structure will now be explained in detail through actions.

[0075] (Installation and activation of smart applications)

[0076] First, in the case where the user terminal is a smartphone or similar device, the smart key application 19 is installed and activated to constitute [the application]. Figure 2 The system shown. In this embodiment, during installation and activation, a user ID is set in the smart key application 19, and the user key / public key generation unit 28 generates a user key / public key 20 based on the user ID and stores it in the data storage unit 14.

[0077] In addition, the secret key and public key can be generated using the user terminal's OS, or they can be generated by other devices (such as a smart key management server 6).

[0078] (Generation of smart contracts)

[0079] Figure 6 This is a flowchart representing the smart contract issuance process of the smart key management server 6.

[0080] First, the user ID receiving unit 56 receives user ID 21 from the user terminal 2 (step S1).

[0081] Next, the smart contract issuance unit 54 issues a smart contract for each vehicle / vehicle device by referring to the vehicle / vehicle device information stored in the vehicle / vehicle device management unit 53 (step S2). At this time, the received user ID is specified as the user type: vehicle owner via the parameters of the constructor of smart contract 4.

[0082] If the smart contract 4 is issued, the Ethereum network generates a smart contract address (Ethereum address) 27, and then associates this address 27 with the vehicle / vehicle device and stores it in the contract address storage unit 55 (step S3). This generated address is a unique identifier for the smart contract.

[0083] Next, the address 27 of the smart contract is registered in the smartphone application 19 (smart key) on the owner's user terminal 2 and in the vehicle device 5 (step S4) (see reference). Figure 2 , Figure 4 The specific registration method varies depending on the system; it can be installed online or offline.

[0084] Therefore, the vehicle-mounted device 5 and the user terminal 2 share the same smart contract address 27, thus enabling them to read and write data to a specific smart contract 4. If they have the permission to refer to the user ID 21, they can also write data to the smart contract 4.

[0085] In addition, in this implementation, each user has an Ethereum address, which is used as a user ID.

[0086] (User authentication on the user terminal)

[0087] Figure 7 This is a flowchart representing the actions of user terminal 2.

[0088] First, the user authentication unit 29 performs user authentication for the user terminal 2 (step S5).

[0089] In this embodiment, user authentication is performed by the OS of the terminal 2 and utilizes passwords and biometric authentication. Furthermore, it can be configured so that the user has a member account on the aforementioned smart key management server 6, in which case they can log in using a specified ID and password.

[0090] If the authentication performed by the user authentication department 29 is successful, then the smart key application 19 enables... Figure 8 The user interface 58 shown in (a) is displayed on user terminal 2.

[0091] (Generation of public key addresses based on user terminals)

[0092] If the user presses the code initialization button shown by 60 in the attached figure (corresponding to the above request input device) on the above user interface 58, the public key address generation unit 30 and the inherent identification code generation unit 31 generate a public key address smaller than the number of bytes of the public key by referring to the user key / public key 20, and generate the user terminal inherent identification code 7 using the public address (steps S6 to S10).

[0093] Taking the case where the public key encryption algorithm is ECDSA as an example, the operation of the public key address generation unit 30 and the inherent identification code generation unit 31 will be explained as follows.

[0094] First, the public key address generation unit 30 retrieves the public key (step S6). The ECDSA public key is 65 bytes long.

[0095] Next, the public key address generation unit 30 uses a hash function (Keccak-256) to hash the ECDSA public key, generating a 256-bit (32-byte) hash value (step S7). Furthermore, the latter 20 bytes are extracted from the 32-byte hash value as the "public key address" (step S8).

[0096] In this implementation, one reason for setting the public key address data size to 20 bytes is to provide a minimum sufficient size for verification that uniquely identifies the public key. Therefore, the public key address can be less than 20 bytes, or of course, greater than 20 bytes, as long as the purpose is achieved.

[0097] (Generation of inherent identification codes based on user terminals)

[0098] If the public key address is generated in the manner described above, the user terminal inherent identification code generation unit 31 will link the unlock password information 24 (the unique identifier of the signing method and the parameters of the signing method) with the public key address and save it as a value, namely the user terminal inherent identification code 7 (steps S9 and S10).

[0099] Specifically, such as Figure 9 As shown, the public key address 62 (20 bytes) is concatenated with the unlocking information (a unique identifier for the signing method and a unique identifier for the signing method parameters (“1.2.840.10045.2.1” and “1.3.132.0.10” respectively in the case of ECC) to form a single value. This value is then binary-encoded to generate and store individual identification code values. Specifically, in this embodiment, the SubjectPublicKeyInfo (SPKI) format encoded in X.509 using ASN.1DER is used.

[0100] If the structure is as described above, the actual public key size can be reduced, the overall SPKI intrinsic identification code 7 size can be reduced, and the storage area of ​​the smart contract can be reduced from 3 slots to 2 slots (in this embodiment).

[0101] Furthermore, the unlocking cipher information (the encryption method and parameters used to generate the public key) is typically not mixed into the public key data. Therefore, even if only the public key is shared, without understanding its context or encryption information, possessing the actual public key data is meaningless as it doesn't reveal how to use it.

[0102] Furthermore, when sharing the public key of an Ethereum user account, it is possible to share only the actual public key data because the public key cryptographic information (method: ECC, parameter: secp256k1) is fixed in the context (Ethereum specification).

[0103] In contrast, in the smart key system according to the embodiments of the present invention, the signing method for the signed request described below needs to handle multiple public key encryption methods, and / or the information encrypted with the public key is not limited in the context. In this environment, when sharing the public key, it is also necessary to share the information encrypted with the public key.

[0104] Furthermore, theoretically, the public key address 62 and the unlocking encryption information 63 could be shared separately. However, this is inconvenient, so in this example, the public key encrypted information and the actual public key data (see reference) are generated and shared as a value (code). Figure 9 ).

[0105] (Writing of inherent identification codes based on user terminals)

[0106] Next, the inherent identification code sending unit 32 writes the inherent identification code 7 generated in the above manner into the smart contract 4 with reference to the smart contract address 27 (step S11).

[0107] In addition, in this embodiment, based on the above-mentioned code, the inherent identification code sending unit 32 also writes the following information (step S11).

[0108] • User ID (In this implementation, the Ethereum address of the user's wallet is used as the user ID)

[0109] • User type (car owner, family member, sharer, etc.)

[0110] • User's key attributes (e.g., key validity period, speed limit when unlocking with the key, etc., binary data in a unique DER-encoded format).

[0111] Write these four values ​​into smart contract 4, which allows you to specify who (the user's address), with what permissions (the user's type), using which key (the user's key), and at what time (the user's key's attributes) will unlock the car.

[0112] Furthermore, in this implementation, a single smart contract 4 can store the "user information" of one car owner (type: car owner) and the "user information" of multiple users (type: family members, sharers, etc.).

[0113] Moreover, only users with the user ID of the user type "car owner" can write to the smart contract.

[0114] Furthermore, in this embodiment, the authentication method for the aforementioned user permissions is configured as a traditional authentication method using Ethereum.

[0115] Specifically, authentication is performed through the following steps.

[0116] (A) The Ethereum network recovers the public key based on the signature of the transaction and the data of the transaction.

[0117] (B) The Ethereum network generates the user's Ethereum address (user ID) based on the recovered public key.

[0118] (C) The Ethereum network delivers the generated Ethereum address to the smart contract as the sender address of the transaction.

[0119] (D) Finally, observe the sender address of the transaction sent to the smart contract on the car smart contract side. If it matches the user ID (Ethereum address) of the user type: car owner, then the write transaction is permitted. If they do not match, the transaction is not permitted.

[0120] Furthermore, in this embodiment, the code is generated using the application 19 installed on the user terminal 2, but the external smart key management server 6 can encode it and execute the writing to the smart contract 4 as described later.

[0121] (Sending a signed request based on the user terminal)

[0122] Next, refer to Figure 10 The flowchart shown illustrates the request sending action of user terminal 2.

[0123] First, if in Figure 8 (a) In the interface, the inherent identification code 7 is written to the aforementioned smart contract. Then, pressing the main screen button 65 will... Figure 8 (b) is displayed using the request command input interface shown in 64.

[0124] In this example, as input requests, unlocking (66), locking (67), starting the engine (68), and opening the trunk (69) are displayed. However, it is not limited to these.

[0125] Furthermore, when a user presses any button to accept a request (step S12), the request command information 26 corresponding to that button is retrieved from the data storage unit 14, and a signed request is generated using the signed request generation unit 34 (step S13). Specifically, the request is symbolized using the key in the user's private / public key information to create an electronic signature, and a request containing the electronic signature is generated.

[0126] Next, the signed request sending unit 35 sends a signed request for vehicle use and a public key to the vehicle-mounted device 5 (step S14). In addition to the request itself, the request may also include vehicle use conditions (e.g., use date and time). The signed request and public key are wirelessly transmitted to the vehicle-mounted device 5 via the vehicle communication equipment.

[0127] Furthermore, the transmission method is not limited to wireless communication; for example, it can be transmitted to the vehicle-mounted device 5 via a network based on a public wireless line network.

[0128] (The operation of the vehicle-mounted device)

[0129] Next, refer to Figure 11 The flowchart illustrates the operation of the vehicle-mounted device 5.

[0130] First, as explained above, this is based on the premise that the address 27 of the smart contract issued using the smart key management server 6 is set in the vehicle device 5. This address is set in the vehicle device 5 either offline or online, as previously described.

[0131] (Read the identification code from the smart contract of the vehicle device)

[0132] Next, the user terminal unique identification code receiving unit 47 reads the user terminal unique identification code 7 from the smart contract associated with the address 27 of the aforementioned smart contract via the transceiver unit 42.

[0133] The timing of downloading this inherent identification code 7 is arbitrary; for example, a request can be made periodically or according to a predetermined schedule.

[0134] (Receive a signed request from the vehicle-mounted device from the user terminal)

[0135] The signed request receiving unit 48 receives the signed request and public key sent from the user terminal 2 via the transceiver unit 42 (step S15).

[0136] (Generation of the public key address for the vehicle-mounted device)

[0137] Next, the public key address generation unit 49 generates a public key address based on the public key received by the signed request receiving unit 48. This generation can be performed using the same method as the generation of the public key address 62 by the public key address generation unit 30 of the user terminal described above (steps S16, S17).

[0138] (Authentication of user terminals for vehicle-mounted devices)

[0139] Next, the user terminal authentication unit 50 authenticates the user terminal 2 using the public key address generated in the above manner. This authentication process is performed through the following two steps (S18 and S19).

[0140] First, the user terminal authentication unit 50 searches whether the public key address generated in the above manner exists in the identification code 7 called from the smart contract. Figure 9 Within the specified range, if a consistent code string (public key address 62) exists, it can be pre-determined that the aforementioned public key and the signed request were sent from the designated user terminal 2 (step S18).

[0141] However, this alone is insufficient for authenticating user terminals. This is because the content of smart contracts and public keys are public information.

[0142] Therefore, the user terminal authentication unit 50 uses the public key to verify the signed request (step S19). If the verification result is positive, it is authenticated that the signed request was sent from the designated user terminal 2.

[0143] Next, the request processing unit 51 receives the authentication result and performs processing based on the completed authentication request (step S20).

[0144] For example, when riding in a vehicle, if a user terminal 2 sends a key unlocking request to the vehicle-mounted device 5, the vehicle-mounted device 5 responds and unlocks the vehicle. Similarly, if a request including locking is sent, the device responds and locks the vehicle.

[0145] Based on the structure described above, the actual public key can be sent directly from the user terminal 2 (the first device) to the vehicle-mounted device 5 (the second device). Therefore, the information shared in the blockchain does not need to be the public key itself; it is sufficient to pre-place "public key data" smaller than the public key at a designated address on the network. This achieves the effect of not compressing the storage area of ​​servers managing smart keys, etc.

[0146] Furthermore, the present invention is not limited to the above-described embodiments, and various modifications can be made without changing the spirit of the invention.

[0147] For example, the above embodiments illustrate an electronic key system utilizing blockchain, but this is just one example; a server on the network could be used instead of blockchain.

[0148] In addition, in one embodiment described above, a smart key used for unlocking and locking a vehicle was used as an example, but it is not limited to this. It can be applied to any system that requires authentication of the first device when sending a request from the first device to the second device.

[0149] For example, it could be a smart key for your own car door, a hotel room key, or other lockers delivered to your home, or a smart device for starting up a specific device such as a personal computer; the requested category can be arbitrary.

[0150] Furthermore, in one of the above embodiments, the aforementioned private and public keys are generated when the smart key application is installed, but this is not a limitation. For example, it can be generated by pressing... Figure 8 The smart key code initialization button 60 is shown to generate the code on a timer.

[0151] Explanation of the label

[0152] ID…user

[0153] 1…Smart Key System

[0154] 2…User Terminal

[0155] 3…Internet

[0156] 4…Smart Contracts

[0157] 5…Vehicle-mounted devices

[0158] 6…Smart Key Management Server

[0159] 7…User terminal inherent identification code

[0160] 10…CPU

[0161] 11…RAM

[0162] 12… Input / Output Section

[0163] 13…bus

[0164] 14…Data Storage Department

[0165] 15…Program Storage Department

[0166] 16…Request input device

[0167] 17…Network communication equipment

[0168] 18…Vehicle-mounted wireless communication equipment

[0169] 19… Smart Key Application

[0170] 20… User key / public key

[0171] 21…User ID

[0172] 22…User Types

[0173] 23…User Key Attributes

[0174] 24…unlock password information

[0175] 26…Request command information

[0176] 27…Smart Contract Address

[0177] 29…User Authentication Department

[0178] 30…Public Key Address Generation Department

[0179] 31…Inherent Identification Code Generation Department

[0180] 32…Inherent Identification Code Transmission Section

[0181] 33…Request Handling Department

[0182] 34…Request Generation Department with Signature

[0183] 35…Signed Request / Public Key Sending Section

[0184] 40… antenna

[0185] 41…Control Department

[0186] 42…Receiving and Dispatch Department

[0187] 43… Operations Department

[0188] 44… Display Section

[0189] 45…Voice Output Section

[0190] 47…User terminal inherent identification code receiving unit

[0191] 48… Signed Request / Public Key Receiving Department

[0192] 49…Public Key Address Generation Department

[0193] 50…User Terminal Authentication Department

[0194] 51…Request Processing Department

[0195] 53…Onboard Equipment Management Department

[0196] 54…Smart Contract Issuance Department

[0197] 55…Smart Contract Address Storage Department

[0198] 56…User ID Receiving Department

[0199] 58…User Interface

[0200] 62…public key address

[0201] 63…Unlocking Encryption Information

[0202] 65…Main Screen Button

[0203] 66…Unlock button

[0204] 67… Lock button

[0205] 68… Engine start button

[0206] 69… Trunk opening button

Claims

1. A request processing system, comprising a first device and a second device associated with the first device, the request processing system is configured to use the second device to receive and execute a request transmitted from the first device, wherein the request processing system is characterized in that, the first device comprises: a unit configured to store a unique private key and a public key; a unit configured to generate first device identification unique data including public key data capable of uniquely identifying the public key, and unlock password data capable of uniquely identifying unlock password information; The generated first device identifies the unit that writes inherent data to a specified address on the communication network; and a request transmission unit configured to transmit a signed request signed with the private key and the public key to the second device, the second device comprises: a unit configured to read the first device identification unique data written to a predetermined address; a unit configured to generate public key data capable of uniquely identifying the public key according to the public key received from the first device, determine whether the public key data is included in the read first device identification unique data, and based on the determination, authenticate the first device by verifying the signature of the signed request based on the public key received from the first device and the unlock password data included in the downloaded first device identification unique data; and a unit configured to execute the verified request based on the authentication of the first device.

2. The request processing system according to claim 1, characterized in that, the first device is a smart key, and the second device is an on-board device that is mounted on a vehicle and controls unlocking and locking of the vehicle according to a request from the first device.

3. The request processing system according to claim 1, characterized in that, the public key data is generated by transforming the public key using a hash function, and has a size smaller than the original public key.

4. The request processing system according to claim 1, characterized in that, the public key data is a public key address used in a blockchain system.

5. The request processing system according to claim 1, characterized in that, the first device identification unique data is written to an address of an Ethereum smart contract.

6. The request processing system according to claim 1, characterized in that, comprising an authentication unit configured to authenticate the write permission of the first device.

7. The request processing system according to claim 1, characterized in that, the first device identification unique data is stored in a system that charges a user according to the size of stored data.

8. The request processing system according to claim 1, characterized in that, the unlock password data capable of uniquely identifying the unlock password information includes a unique identifier of a signature scheme and a unique identifier of a parameter of the signature scheme.

9. A request processing method, implemented by a request processing system, the request processing system comprising a first device and a second device associated with the first device, and being configured to use the second device to receive and execute a request transmitted from the first device, the request processing method is characterized in that, a computer serving as the first device executes the following steps: a step of storing a unique private key and a public key; A process of generating inherent data for identification of a first device, including public key data that can uniquely identify the public key and unlocking password data that can uniquely identify the unlocking password information; The process of identifying the generated first device and writing inherent data to a specified address on the communication network; and The process of sending a signed request, signed with the key, and the public key to the second device. The computer in the second device performs the following steps: The process of reading out inherent data from the first device that writes to the specified address; The process of generating public key data that uniquely identifies the public key based on the public key received from the first device, determining whether the read-out first device identification proprietary data contains the public key data, and authenticating the first device by verifying the signature of the signed request based on the public key received from the first device and the unlocking password data contained in the downloaded first device identification proprietary data; and The process of executing the verification completion request based on the authentication of the first device.

10. The request processing method according to claim 9, characterized in that, The first device is a smart key, and the second device is an on-board device mounted on the vehicle and controlling the unlocking and locking of the vehicle according to the request of the first device.

11. The request processing method according to claim 9, characterized in that, The public key data is generated by transforming the public key using a hash function, and its size is smaller than the original public key.

12. The request processing method according to claim 9, characterized in that, The public key data is the public key address used in the blockchain system.

13. The request processing method according to claim 9, characterized in that, The first device identifies the address of the smart contract written to Ethereum with inherent data.

14. The request processing method according to claim 9, characterized in that, An authentication process that has the write permission to authenticate the first device.

15. The request processing method according to claim 9, characterized in that, The first device identifies a system that stores inherent data and charges the user based on the size of the stored data.

16. The request processing method according to claim 9, characterized in that, The unlocking password data that can uniquely identify the unlocking password information includes a unique identifier for the signature method and a unique identifier for the parameters of the signature method.

Images