Request processing system

Abstract

SOLUTION: There is provided a request processing system that is configured to cause a second device to receive a request transmitted from a first device and to execute the request, in which the first device has: means for writing generated unique data for identifying the first device in a specified address on a communication network and request transmission means for transmitting a signed request signed by a secret key, and a public key to the second device, and the second device has: means for reading the unique data for identifying the first device; means for generating public key data capable of uniquely identifying the public key from the received public key, determining whether the public key data is included in downloaded unique data for identifying the first device, and authenticating the first device by verifying the signature of the signed request based on the public key received from the first device and key-opening encryption data included in the downloaded unique data for identifying the first device based on the determination; and means for executing the verified request based on the authentication of the first device.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a request processing system and method for processing requests for locking and unlocking vehicles, houses, lockers, etc. using electronic devices such as smart keys.

Background Art

[0002] The practical application of a smart key system for locking or unlocking doors of vehicles, lockers, etc. without using a physical key has been promoted, and the following technologies are available as prior arts.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] Here, according to a certain statistic, the average service life of automobiles in Japan in 2017 was 12.91 years. On the other hand, in the case of a smart key for locking and unlocking a vehicle, it is common for a specific private company to manage the system, and there is no guarantee that the management service can be continuously provided over the entire service life of the automobile. Also, when the cost of managing the smart key is too high, the burden is too large and it becomes difficult to continue the service.

[0005] The present invention has been made in view of such circumstances, and an object of the present invention is to provide a system that can provide services more generally without relying on a specific service provider in a request processing device that processes requests between a smart key and an in-vehicle device.

Means for Solving the Problems

[0006] In order to achieve the above object, when using the technology of authenticating the first device and the second device using a public key, in view of the fact that storing the actual public key in a server would compress the storage area, the inventors of the present invention conceived of a device that can perform accurate authentication without sharing the public key on the network, and completed the present invention by performing a good faith verification.

[0007] That is, according to the first main aspect of the present invention, the following invention is provided.

[0008] (1) A request processing system having a first device and a second device associated with the first device, for receiving a request transmitted from the first device at the second device and causing the second device to execute the request, wherein the first device has means for holding a unique secret key and a public key, means for generating unique data for identifying the first device, including public key data that can uniquely identify the public key and is smaller in size than this public key, and key encryption data that can uniquely identify key encryption information, means for writing the generated unique data for identifying the first device to a predetermined address on a communication network, and request transmission means for transmitting the signed request signed with the secret key and the public key to the second device and has wherein the second device has means for reading the unique data for identifying the first device written to the predetermined address, generates public key data that can uniquely identify the public key from the public key received from the first device, determines whether this public key data is included in the downloaded unique data for identifying the first device, and based on this determination, verifies the signature of the signed request based on the public key received from the first device and the key encryption data included in the downloaded unique data for identifying the first device, thereby authenticating the first device. Means for executing the verified request based on the authentication of the first device A request processing system having the same.

[0009] According to such a configuration, when a request is sent from a first device to a second device, a public key is sent to the second device together with this request. Then, at the second device, public key data that can uniquely identify the above public key and has a small size is generated and compared with unique data called from a predetermined address on the network, and the signature made in the request is verified using specific key data, whereby the user terminal can be authenticated.

[0010] According to this, since the actual public key can be directly sent from the first device to the second device, the information to be shared does not need to be the public key itself, and "public key data" having a smaller size than this public key can be placed at a predetermined address on the network. As a result, it is possible to obtain the effect of not compressing the storage area of a server that manages smart keys or the like.

[0011] Here, according to one embodiment of the present invention, it is preferable that the first device is a smart key, and the second device is an in-vehicle device mounted on a vehicle and controlling unlocking and locking of the vehicle according to a request of the first device.

[0012] Further, according to another embodiment of the present invention, the public key data is preferably a hash value generated by converting a public key using a hash function, and more preferably, the last 20 bytes of this hash value are extracted, which is a public key address used in a blockchain system.

[0013] According to still another embodiment of the present invention, the unique data for identifying the first device is preferably written to the address of a smart contract of Etheruem. According to this, if a user terminal unique identification code is stored on a blockchain network, the universality of code storage can be ensured.

[0014] According to still another embodiment of the present invention, preferably, the system transmits information for identifying the first device to the predetermined address in order to authenticate the writing authority by the first device.

[0015] In addition, features of the present invention other than those described above can be understood by those skilled in the art by referring to the description of the embodiments of the present invention described below and the attached drawings.

Brief Description of the Drawings

[0016]

Figure 1

Figure 2

[0017]

Figure 3

[0018]

Figure 4

[0019]

Figure 5

[0020]

Figure 6

[0021]

Figure 7

[0022]

Figure 8

[0023]

Figure 9

Figure 10

[0024]

Figure 11

DETAILED DESCRIPTION OF THE INVENTION

[0025] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0026] FIG. 1 is an overall configuration diagram showing an example in which the request processing system of the present invention is applied to a smart key system 1 for locking and unlocking a vehicle door.

[0027] (Overall Configuration) This smart key system 1 includes one or more user terminals 2 (corresponding to the "first device" of the present invention), a smart contract 4 (corresponding to the "predetermined address on the network" of the present invention) connected to the user terminal 2 via the Internet 3, an in-vehicle device 5 mounted on the vehicle (corresponding to the "second device" of the present invention), and a smart key management server 6 for managing the smart key system 1.

[0028] In this smart key system 1, the user terminal 2 writes a user terminal unique identification code (unique data for identifying the first device) 7 to the smart contract 4 in advance (A). On the other hand, the in-vehicle device 5 calls the user terminal unique identification code 7 from the smart contract 4 (B) and stores it in the user terminal 2. When a user of the vehicle transmits a specific request to the in-vehicle device 5 of the vehicle using the user terminal 2 owned by the user, the in-vehicle device 5 is configured to perform authentication of the user terminal 2 using the user terminal unique identification code 7.

[0029] (Smart contract) Here, the smart contract 4 is a computer protocol built on Ethereum. When the contract and its execution conditions are programmed in advance, a mechanism is in place such that transactions are automatically conducted when the contract conditions are met.

[0030] In Ethereum, it is configured to record the execution history of the smart contract 4 on a blockchain on a P2P network called the Ethereum network. Ethereum has a programmable language that can be tuned to describe the smart contract 4, and network participants can describe any smart contract 4 on the blockchain on this network and execute it. With such a mechanism, it has become possible to share the execution of programs and their results with the entire P2P as the execution environment without relying on a specific central management organization.

[0031] (User terminal) The user terminal 2 is typically a smartphone, but it may also be a tablet or other computer device.

[0032] Also, in this embodiment, as types of users who use this user terminal 2, three types are set: the owner who owns a vehicle, their family members, and car-sharing users. For example, in a car-sharing service, the operator conducting the car-sharing business is the owner who owns the vehicle, and the person sharing the vehicle is a car-sharing user who only uses the vehicle. The same applies to car rental services, where the operator conducting the car rental business is the owner who owns the vehicle, and the person renting the vehicle is a car-sharing user who uses the vehicle. Also, in the case of a private car, the person in whose name the vehicle is registered is the owner, and the family member driving the vehicle is the user who uses the vehicle.

[0033] In this embodiment, as will be described in detail later, the authority to write to the smart contract 4 varies according to the type of user.

[0034] (In-vehicle device) The in-vehicle device 5 is an electronic device mounted on a vehicle and has a function of controlling the locking or unlocking of the vehicle door. In addition to the above function, this in-vehicle device 5 can also be provided with other functions, such as a highway toll payment function, a navigation-audio-visual function, and the like.

[0035] In this embodiment, a unique address (smart contract address) of the smart contract 4 is assigned to each in-vehicle device 5, and the user terminal 2 writes the user terminal unique identification code 7 to this smart contract address (indicated by A in FIG. 1). Then, the in-vehicle device 5 calls and stores the written user terminal unique identification code 7 (indicated by B in FIG. 1). And when receiving a signed request and a public key from the user terminal 2 (indicated by C in FIG. 1), the in-vehicle device 5 compares the user terminal identification individual code 7 with the public key and verifies the signature of the signed request (locking or unlocking), thereby authenticating the user terminal 2, and then appropriately processes the request.

[0036] (Smart key management server) Also, the smart key management server 6 is, for example, operated by the applicant of this application, and has a function of generating a smart contract 4 for each in-vehicle device on the blockchain, and a function of setting the address of the smart contract to the user terminal 2 and the in-vehicle device 5.

[0037] Hereinafter, the configurations of each device 2 to 6 will be described in detail.

[0038] (Detailed configuration of user terminal) FIG. 2 is a schematic configuration diagram showing the user terminal 2.

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

[0040] (Data storage unit) Only listing the data related to this invention, the data storage unit 14 stores a user's private key and public key 20, a user ID 21 (in this embodiment, an Ethereum address), a user type 22 (owner, family, share), a user key attribute 23 (such as the expiration date of the key), encrypted key information 24, a user terminal unique identification code 7, request command information 26 (such as unlocking and locking), and the address of the smart contract 27 (Ethereum address).

[0041] (Program storage unit) Also, only listing the configurations related to this invention, the program storage unit 15 stores a user private key / public key generation unit 28, a user authentication unit 29, a public key address generation unit 30, a user terminal unique identification code generation unit 31, a unique identification code transmission unit 32, a request reception unit 33, a signed request generation unit 34, and a signed request / public key transmission unit 35.

[0042] Specifically, the data storage unit 14 and the program storage unit 15 are the auxiliary storage devices (HDD or SDD) of this user terminal 2. Also, some or all of the functional units 29 to 35 stored in the program storage unit 15 are configured as the "smart key app 19" (see FIG. 1) installed in the user terminal 2. Further, when installing this app 19, a space for storing each piece of information 20 to 27 of the data storage unit 14 is secured in the auxiliary storage device of the user terminal 2.

[0043] Each piece of information 20 to 27 in the data storage unit 14 may be each table in the database and the values stored therein, or may be directly written as a program in each functional unit 29 to 35 stored in the program storage unit 15. Also, since the user's private key needs to be managed in as secure a way as possible, it is preferably stored in the secure element provided by the user terminal (such as a smartphone).

[0044] And each functional unit 29 to 35 stored in the program storage unit 15 is configured to function as each component described in the claims of this application by being appropriately called and expanded and executed on the RAM 11 by the CPU 10.

[0045] (In-vehicle device) FIG. 3 is a schematic configuration diagram showing the in-vehicle device 5.

[0046] This in-vehicle device 5 includes a control unit 41, a transmission / reception unit 42 connected to the control unit 41, an operation unit 43, a display unit 44, and an audio output unit 45. An antenna 40 for directly performing wireless communication with the user terminal 2 is provided in the transmission unit 42, and it can be connected to the Internet 3 to communicate with the smart contract 4 and the smart key management server 6.

[0047] FIG. 4 is a functional block diagram showing the configuration implemented in the control unit 41.

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

[0049] (Smart key management server) Further, FIG. 5 is a functional block diagram schematically showing the smart key management server 6.

[0050] This smart key management server 6, when showing only the configuration related to this invention, has a vehicle / vehicle-mounted device management unit 53, a smart contract issuance unit 54, a smart contract address storage unit 55, and a user ID reception unit 56.

[0051] Hereinafter, the above configuration will be described in detail through operations.

[0052] (Installation and activation of the smart app) First, when the user terminal is a smartphone or the like, by installing and activating the smart key app 19 described above, the system shown in FIG. 2 is configured. In this embodiment, when installing and activating, a user ID is set in the smart key app 19, and based on this user ID, the user secret key / public key generation unit 28 generates a user secret key / public key 20 and stores it in the data storage unit 14.

[0053] Note that the generation of this secret key and public key may be performed using the OS of the user terminal, or those generated by another device (for example, the smart key management server 6 etc.) may be used.

[0054] (Generation of smart contract) FIG. 6 is a flowchart showing the smart contract issuance process in the smart key management server 6.

[0055] First, the user ID reception unit 56 receives a user ID 21 from the user terminal 2 (step S1).

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

[0057] After issuing the smart contract 4, since the Ethereum network generates the address (Ethereum address) 27 of the smart contract, this address 27 is associated with the vehicle and in-vehicle device and stored in the contract address storage unit 55 (step S3). This generated address becomes the unique identifier of the smart contract.

[0058] Next, this smart contract address 27 is registered in the smartphone app 19 (smart key) on the user terminal 2 of the vehicle owner and the in-vehicle device 5 (step S4) (see FIGS. 2 and 4). The specific registration method varies depending on the system, and it can be either online or offline installation.

[0059] As a result, the in-vehicle device 5 and the user terminal 2 share the same smart contract address 27, so it is possible to read the data written in a specific smart contract 4, and if there is permission by referring to the user ID 21, it is also possible to write data to the smart contract 4.

[0060] In this embodiment, each user has an Ethereum address, which is used as the user ID.

[0061] (User authentication on the user terminal) FIG. 7 is a flowchart showing the operations on the user terminal 2.

[0062] First, the user authentication unit 29 performs user authentication on this user terminal 2 (step S5).

[0063] In this embodiment, the user authentication uses the password or biometric authentication executed by the OS of this terminal 2. Note that it is also possible to configure the user to have a membership account on the smart key management server 6. In this case, the user may log in to the membership account using a predetermined ID and password.

[0064] If the authentication by this user authentication unit 29 is successful, this smart key application 19 displays a user interface 58 as shown in Fig. 8(a) on the user terminal 2.

[0065] (Generation of Public Key Address by User Terminal) When the user presses the code initialization button 60 (corresponding to the request input device) shown in the figure on the user interface 58, the public key address generation unit 30 and the unique identification code generation unit 31 refer to the user private key / public key 20, generate a public key address with a size smaller than the number of bytes of the public key, and generate a user terminal unique identification code 7 using this public address (steps S6 to S10).

[0066] Taking the case where the public key encryption algorithm is ECDSA as an example, the operations of the public key address generation unit 30 and the unique identification code generation unit 31 are as follows.

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

[0068] Next, the public key address generation unit 30 hashes the ECDSA public key using a hash function (Keccak-256) to generate a hash value of 256 bits (32 bytes) (step S7). Then, the latter 20 bytes are extracted from the 32-byte hash value as the "public key address" (step S8).

[0069] In this embodiment, one reason for setting the data size of the public key address to 20 bytes is that it has been verified as one of the minimum sizes sufficient to uniquely identify the public key. Therefore, as long as the purpose can be achieved, the public key address may have fewer bytes than 20 bytes, or of course, may have more bytes than 20 bytes.

[0070] (Generation of Identification Unique Code by User Terminal) If the public key address has been generated as described above, the user terminal unique identification code generation unit 31 concatenates the key encryption information 24 (unique identifier of the signature method and parameters of the signature method) to this public key address and stores it as the user terminal unique identification code 7 which is one value (steps S9, S10).

[0071] Specifically, as shown in FIG. 9, the public key address 62 (20 bytes) is concatenated with the key information (unique identifier of the signature method and unique identifier of the parameters of the signature method (in the case of ECC, “1.2.840.10045.2.1” and “1.3.132.0.10” respectively)) to form one value, and is binary-encoded to generate and store it as an individual identification code value. As a specific data format, in this embodiment, the format of SubjectPublicKeyInfo (SPKI) of X.509 encoded by ASN.1 DER is used.

[0072] With the configuration as described above, the smaller the size of the actual public key can be made, the smaller the size of the entire SPKI unique identification code 7 will be, and the storage area in the smart contract can be reduced, for example, from 3 slots to 2 slots (in this embodiment).

[0073] Note that usually, the key encryption information (public key encryption method and parameters) used to generate the public key is not included in the public key data. Therefore, even if only the public key is shared, without knowing the context or encryption information of this public key, even if one has the actual public key data, one does not know how to use it, which means it is meaningless.

[0074] In addition, when sharing the public key of an Ethereum user account, only the actual public key data can be shared, because the information of public key cryptography (method: ECC, parameter: secp256k1) is fixed in the context (Ethereum specifications).

[0075] On the other hand, in the smart key system according to the embodiment of the present invention, it is necessary to support a plurality of public key cryptography methods as the signature method of the signed request to be described later, and / or the information of public key cryptography is not limited in the context. When sharing the public key in such an environment, it is necessary to share the information of public key cryptography as well.

[0076] Also, theoretically, it is possible to share the public key address 62 and the key encryption information 63 separately. However, since it is inconvenient, in this example, the information of public key cryptography and the data of the actual public key are generated and shared as one value (code) (see FIG. 9).

[0077] (Writing of unique identification code by user terminal) Next, the unique identification code transmission unit 32 writes the unique identification code 7 generated above to the smart contract 4 with reference to the smart contract address 27 (step S11).

[0078] Also, in this embodiment, the unique identification code transmission unit 32 writes the following information in addition to the above code (step S11). · User ID (in this embodiment, the Ethereum address of the user's wallet is used as the user ID) · User type (owner, family, share, etc.) · Attributes of the user's key (for example, the validity period of the key, the speed limit of the car when unlocking with this key, etc. Binary data in a unique format encoded in DER).

[0079] By writing the four added values into the smart contract 4, it becomes possible to specify who (user address), with what authority (user type), with which key (user key), and for what period of time (user key attribute) the car can be opened.

[0080] In this embodiment, it is possible to store the "user information" of one car owner (type: owner) and the "user information" of multiple users (types: family, share, etc.) in one smart contract 4.

[0081] Only the user with the user ID of the user type "owner" can write to the smart contract.

[0082] In this embodiment, as the above user authority authentication method, it is configured to use the traditional authentication method of Ethereum.

[0083] Specifically, the authentication is executed by the following steps.

[0084] (A) The Ethereum network restores the public key from the signature of the transaction and the transaction data.

[0085] (B) The Ethereum network generates the user's Ethereum address (user ID) from the restored public key.

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

[0087] (D) Finally, on the car smart contract side, by looking at the sender address of the transaction that has reached the smart contract, if it matches the user ID (Ethereum address) of the user type: owner, the write transaction is permitted, and if it does not match, the transaction is not permitted.

[0088] In this embodiment, the generation of this code is performed by the application 19 installed on the user terminal 2. However, it may be encoded by an external smart key management server 6, and it may also be done up to the writing to the smart contract 4 which will be described later.

[0089] (Transmission of a signed request by the user terminal) Next, the request transmission operation by the user terminal 2 will be described with reference to the flowchart shown in FIG. 10.

[0090] First, if the unique identification code 7 has been written to the above smart contract on the interface of FIG. 8(a), by pressing the main screen button 65, the request command input interface shown by 64 in FIG. 8(b) is displayed.

[0091] In this example, as requests that can be input, unlocking 66, locking 67, engine start 68, and trunk open 69 are displayed. However, it is not limited to this.

[0092] Then, when the user presses any button, the request is accepted (step S12), and the request command information 26 corresponding to the button is retrieved from the data storage unit 14, and a signed request is generated by the signed request generation unit 34 (step S13). Specifically, an electronic signature is created by encoding the request using the private key in the user private key / public key information, and a signed request including this electronic signature is generated.

[0093] Next, the signed request transmission unit 35 transmits a signed request and a public key for using the vehicle to the in-vehicle device 5 (step S14). This request can also include vehicle usage conditions (for example, usage date and time, etc.) in addition to the request itself. This signed request and public key are wirelessly transmitted to the in-vehicle device 5 through the vehicle communication device.

[0094] Note that the transmission method is not limited to wireless communication. For example, it may be transmitted to the in-vehicle device 5 via a network using a public wireless network.

[0095] (Operation of In-Vehicle Device) Next, the operation of the in-vehicle device 5 will be described with reference to the flowchart of FIG. 11.

[0096] First, as described above, it is assumed that the address 27 of the smart contract issued by the smart key management server 6 is set in this in-vehicle device 5. This address is set in this in-vehicle device 5 offline or online as described above.

[0097] (Reading Identification Code from Smart Contract in In-Vehicle Device) Next, the user terminal unique identification code receiving unit 47 refers to the address 27 of the smart contract and reads the user terminal unique identification code 7 from the smart contract related to the address 27 via the transmission / reception unit 42.

[0098] The timing for downloading this unique identification code 7 is arbitrary. For example, it may be requested periodically or according to a determined schedule.

[0099] (Receiving Signed Request from User Terminal in In-Vehicle Device) The signed request receiving unit 48 receives the signed request and the public key transmitted from the user terminal 2 via the transmission / reception unit 42 (step S15).

[0100] (Generating Public Key Address in In-Vehicle Device) Next, the public key address generating unit 49 generates a public key address from the public key received by the signed request receiving unit 48. This generation is executed in the same manner as the generation of the public key address 62 by the public key address generating unit 30 of the user terminal described above (steps S16, S17).

[0101] (Authentication of User Terminal in In-Vehicle Device) Next, the user terminal authentication unit 50 authenticates the user terminal 2 using the public key address generated above. This authentication process is performed by the following two steps (steps S18 and S19).

[0102] First, the user terminal authentication unit 50 searches for whether the public key address generated above exists in the identification code 7 (Fig. 9) called from the smart contract. If a matching code string (public key address 62) exists, it can be tentatively determined that the public key and the signed request were sent from a predetermined user terminal 2 (step S18).

[0103] However, this alone is not sufficient for user terminal authentication. This is because the content of the smart contract and the public key are both public information.

[0104] Therefore, the user terminal authentication unit 50 verifies the signed request using the public key (step S19). If the verification result is positive, the signed request is authenticated as having been sent from a predetermined user terminal 2.

[0105] Next, upon receiving the authentication result, the request processing unit 51 executes processing based on the verified request (step S20).

[0106] For example, when getting into the vehicle, if a key unlocking request is sent from the user terminal 2 to the in-vehicle device 5, in response, the in-vehicle device 5 unlocks the vehicle. Similarly, if a request including locking is sent, the vehicle is locked in response.

[0107] According to the configuration described above, since the actual public key can be directly sent from the user terminal 2, which is the first device, to the in-vehicle device 5, which is the second device, the information shared on the blockchain does not need to be the public key itself. Instead, "public key data" that is smaller in size than this public key can be placed at a predetermined address on the network. As a result, the effect of not compressing the storage area of the server that manages the smart key or the like can be obtained.

[0108] Note that the present invention is not limited to the above-described embodiments, and various modifications can be made without changing the gist of the invention.

[0109] For example, in the above embodiment, an electronic key system using a blockchain is exemplified, but this is just an example, and a server on the network may be used instead of the blockchain.

[0110] Also, in the above embodiment, the smart key for unlocking and locking the vehicle is taken as an example for explanation, but the present invention is not limited thereto, and it is applicable to any system that requires authentication of the first device when sending a request from the first device to the second device.

[0111] For example, it may be a smart key used for a home door, a hotel room key, or a home delivery locker, or it may be a smart device for starting a specific device such as a personal computer, and the type of request is not particularly limited.

[0112] Furthermore, in the above embodiment, the secret key and the public key are generated when installing the smart key application, but the present invention is not limited thereto. For example, they may be generated at the timing of pressing the smart key code initialization button 60 shown in FIG. 8.

Explanation of Reference Numerals

[0113] ID…User 1…Smart Key System 2…User Terminal 3… Internet 4… Smart contract 5… In-vehicle device 6… Smart key management server 7… User terminal unique identification code 10… CPU 11… RAM 12… Input / output unit 13… Bus 14… Data storage unit 15… Program storage unit 16… Request input device 17… Network communication device 18… In-vehicle device wireless communication device 19… Smart key app 20… User private key · public key 21… User ID 22… User type 23… User key attribute 24… Encryption key information 26… Request command information 27… Smart contract address 29… User authentication unit 30… Public key address generation unit 31… Unique identification code generation unit 32… Unique identification code transmission unit 33… Request reception unit 34… Signed request generation unit 35… Signed request · public key transmission unit 40… Antenna 41… Control unit 42… Transceiver unit 43… Operation unit 44… Display unit 45… Audio output unit 47… User terminal unique identification code reception unit 48… Signed request · public key reception unit 49… Public key address generation unit 50… User terminal authentication unit 51… Request processing unit 53… In-vehicle device management unit 54… Smart contract issuance unit 55…Smart contract address storage unit 56…User ID receiving unit 58…User interface 62…Public key address 63…Key encryption information 65…Main screen button 66…Unlock button 67…Closing button 68…Engine start button 69…Trunk open button

Claims

1. A request processing apparatus that receives a signed request and a public key from an external device and executes the request included in the signed request, means for downloading unique data for identifying an external device written at a predetermined address on a communication network, wherein the unique data includes public key data that can uniquely identify a public key unique to the external device and key encryption data that can uniquely identify key encryption information, the said means, means for generating public key data that can uniquely identify this public key from the public key received from the external device and determining whether this public key data is included in the unique data for identifying the external device downloaded, and based on this determination, verifying the signature of the signed request based on the public key received from the external device and the key encryption information identified by the key encryption data included in the unique data for identifying the external device downloaded, thereby authenticating the external device, means for executing the verified signed request based on the authentication of the external device A request processing system having

2. In the request processing system according to Claim 1, The external device is a smart key, and the request processing device is an in-vehicle device mounted on a vehicle and controlling unlocking and locking of the vehicle according to a request from the external device. A request processing device characterized by

3. In the request processing system according to Claim 1, The public key data is generated by converting the public key using a hash function and is smaller in size than the original public key A system characterized by

4. In the system according to Claim 1, The public key data is a public key address used in a blockchain system A system characterized by

5. In the system according to Claim 1, The unique data for identifying the external device is written to the address of a smart contract of Ethereum A system characterized by

6. In the system according to Claim 1, Having authentication means for authenticating the writing authority of the external device A system characterized by

7. In the system according to Claim 1, The unique data for identifying the external device is stored in a system that charges a user according to the data size to be stored A system characterized by

8. In the system according to claim 1, the key encryption data that can uniquely identify the key encryption information includes the unique identifier of the signature method and the unique identifier of the parameters of the signature method. A system characterized by this.

9. A request processing method in which a computer receives a signed request and a public key from an external device and executes the request included in the signed request, wherein the computer downloads unique data for identifying an external device written at a predetermined address on a communication network, and the unique data includes public key data that can uniquely identify a public key unique to the external device and key encryption data that can uniquely identify key encryption information; the above step, the computer generates public key data that can uniquely identify this public key from the public key received from the external device, determines whether this public key data is included in the unique data for identifying the external device downloaded above, and based on this determination, verifies the signature of the signed request based on the public key received from the external device and the key encryption information identified by the key encryption data included in the unique data for identifying the external device downloaded above, thereby authenticating the external device; the computer executes the verified signed request based on the authentication of the external device A request processing method having.

10. In the request processing method according to claim 9, the external device is a smart key, and the method is characterized in that it is executed by an in-vehicle device mounted on a vehicle and controlling unlocking and locking of the vehicle according to a request of the external device.

11. In the request processing method according to claim 9, the public key data is generated by converting the public key using a hash function and is smaller in size than the original public key. A method characterized by this.

12. In the method according to claim 9, the public key data is a public key address used in a blockchain system. A method characterized by this.

13. In the method according to claim 9, the unique data for identifying the external device is written to the address of a smart contract of Ethereum. A method characterized by this.

14. In the method according to claim 9, having an authentication step of authenticating the writing authority of the external device A method characterized by the above.

15. In the method according to Claim 9, the unique data for identifying the external device is stored in a system that collects charges from the user according to the data size to be stored A method characterized by the above.

16. In the method according to Claim 9, the key encryption data that can uniquely identify the key encryption information includes the unique identifier of the signature method and the unique identifier of the parameters of the signature method A method characterized by the above.

Images