CN112669147B

CN112669147B - Service request method and device based on block chain

Info

Publication number: CN112669147B
Application number: CN202011529847.0A
Authority: CN
Inventors: 顾俊
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2019-12-31
Filing date: 2019-12-31
Publication date: 2023-09-26
Anticipated expiration: 2039-12-31
Also published as: CN111127021A; CN112669147A; CN111127021B

Abstract

The present specification provides a service request method and apparatus based on a blockchain storing a secure access key generated by a service caller and a corresponding access key ID; the secure access key is encrypted in advance based on a public key of a service provider; the method comprises the following steps: the service provider receives a service request sent by the service calling party; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameter based on the secure access key; inquiring a corresponding encrypted security access key based on the access key ID; decrypting the secure access key based on the private key of the service caller, and verifying the first digital signature based on the decrypted secure access key; when the first digital signature is verified, the service request is performed based on the request parameters.

Description

Service request method and device based on block chain

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a blockchain-based service request method and apparatus.

Background

Blockchain technology, also known as distributed ledger technology, is an emerging technology that is commonly engaged in "accounting" by several computing devices, together maintaining a complete distributed database. The blockchain technology has the characteristics of decentralization, disclosure transparency, capability of participating in database recording by each computing device and capability of rapidly performing data synchronization among the computing devices, so that the blockchain technology is widely applied in a plurality of fields.

Disclosure of Invention

In view of this, one or more embodiments of the present description provide a blockchain-based service request method, apparatus, computer device, and computer-readable storage medium.

To achieve the above object, one or more embodiments of the present specification provide a service request method based on a blockchain storing a secure access key generated by a service caller and a corresponding access key ID; the secure access key stored by the blockchain is encrypted in advance based on a public key of a service provider; the method comprises the following steps:

the service provider receives a service request sent by the service calling party; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameter based on the secure access key;

Inquiring a corresponding encrypted security access key based on the access key ID;

decrypting the secure access key based on the private key of the service caller, and verifying the first digital signature based on the decrypted secure access key;

when the first digital signature is verified, the service request is performed based on the request parameters.

In yet another illustrated embodiment, the blockchain has disposed thereon a smart contract for managing secure access keys; processing logic corresponding to a contract code in the intelligent contract comprises key inquiry logic;

the querying the corresponding encrypted secure access key based on the access key ID includes:

constructing an intelligent contract call transaction; wherein the smart contract call transaction includes the access key ID;

issuing the intelligent contract invoking transaction to a blockchain network to invoke the key querying logic in the intelligent contract by node devices in the blockchain network in response to the intelligent contract invoking transaction, and querying a corresponding encrypted secure access key based on the access key ID.

In yet another illustrated embodiment, the secure access key and corresponding access key ID are stored in an account storage space of a contract account corresponding to the smart contract;

and inquiring a corresponding encrypted security access key in an account storage space of a contract account corresponding to the intelligent contract based on the access key ID.

In yet another illustrated embodiment, the processing logic corresponding to the contract code in the smart contract further includes digital signature verification logic;

the decrypting the secure access key based on the private key of the service caller and verifying the first digital signature based on the decrypted secure access key includes:

and after inquiring the corresponding encrypted secure access key based on the access key ID, further calling the digital signature verification logic in the intelligent contract, decrypting the secure access key based on the private key of the service calling party, and verifying the first digital signature based on the decrypted secure access key.

In a further illustrated embodiment, the verifying the first digital signature based on the decrypted secure access key includes:

digitally signing the request parameters based on the decrypted secure access key to obtain a second digital signature;

Determining whether the first digital signature and the second digital signature match; if so, it is determined that the first digital signature is verified.

In yet another illustrated embodiment, before further invoking the key lookup logic in the smart contract, further comprising:

verifying whether the sender of the smart contract invocation transaction is a service provider; if so, the key query logic in the smart contract is further invoked.

In yet another illustrated embodiment, the smart contract invocation transaction further includes an identification ID of the service provider; the verifying whether the sender of the smart contract invocation transaction is the service provider comprises:

inquiring whether the identification ID of the service provider belongs to a key inquiry authority white list stored in the intelligent contract;

if so, the intelligent contract invokes the sender of the transaction as the service provider.

Accordingly, one or more embodiments of the present specification further provide a blockchain-based service request method for a service invocation to send a service request to a service provider, including:

the service calling party generates a secure access key and a corresponding access key ID, and encrypts the secure access key based on a public key of the service provider;

Transmitting the encrypted secure access key and the access key ID to the blockchain, so that the encrypted secure access key and the access key ID are commonly authenticated by node equipment of the blockchain and then stored in the blockchain;

sending a service request to the service provider; the service request comprises a request parameter, the access key ID and a first digital signature obtained by carrying out digital signature processing on the request parameter based on the secure access key, so that the service calling party inquires a corresponding encrypted secure access key based on the access key ID, decrypts the secure access key based on a private key of the service calling party, verifies the first digital signature based on the decrypted secure access key, and executes the service request based on the request parameter when the first digital signature is verified to pass.

In yet another illustrated embodiment, the blockchain has disposed thereon a smart contract for managing secure access keys; processing logic corresponding to a contract code in the intelligent contract comprises key issuing logic;

the sending the encrypted secure access key and the access key ID to the blockchain so that the encrypted secure access key and the access key ID are commonly authenticated by a node device of the blockchain and then stored in the blockchain, including:

Constructing a key issuing call transaction, wherein the key issuing call transaction comprises the encrypted security access key and the access key ID;

and issuing the key issuing call transaction to a blockchain network, so that node equipment in the blockchain network responds to the key issuing call transaction to call the key issuing logic in the intelligent contract, and storing the encrypted security access key and the corresponding access key ID in an account storage space of a contract account corresponding to the intelligent contract.

In yet another illustrated embodiment, the storing the encrypted and corresponding access key ID in an account storage space of a contract account corresponding to the smart contract includes:

querying whether the access key ID is matched with the existing access key ID stored in the account storage space;

and if not, storing the secure access key and the corresponding access key ID in an account storage space of a contract account corresponding to the intelligent contract.

Accordingly, the present specification also provides a service request apparatus based on a blockchain storing a secure access key generated by a service caller and a corresponding access key ID; the secure access key stored by the blockchain is encrypted in advance based on a public key of a service provider; the apparatus is applied to the service provider, and comprises:

A receiving unit for receiving a service request sent by the service calling party; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameter based on the secure access key;

a query unit configured to query a corresponding encrypted secure access key based on the access key ID;

a verification unit that decrypts the secure access key based on the private key of the service caller, and verifies the first digital signature based on the decrypted secure access key;

and an execution unit that executes the service request based on the request parameter when the first digital signature is verified.

the query unit is further configured to:

the verification unit is further configured to:

In a further illustrated embodiment, the verification unit is further configured to, prior to further invoking the key lookup logic in the smart contract:

Accordingly, the present disclosure further provides a service request device based on a blockchain, configured to send a service request to a service provider by using a service calling party, where the device is applied to the service calling party, and includes:

The generation unit generates a secure access key and a corresponding access key ID, and encrypts the secure access key based on a public key of the service provider;

a transmitting unit configured to transmit the encrypted secure access key and the access key ID to the blockchain, so that the encrypted secure access key and the access key ID are stored in the blockchain after being authenticated by a node device of the blockchain;

the transmitting unit is further configured to: sending a service request to the service provider; the service request comprises a request parameter, the access key ID and a first digital signature obtained by carrying out digital signature processing on the request parameter based on the secure access key, so that the service calling party inquires a corresponding encrypted secure access key based on the access key ID, decrypts the secure access key based on a private key of the service calling party, verifies the first digital signature based on the decrypted secure access key, and executes the service request based on the request parameter when the first digital signature is verified to pass.

the transmitting unit is further configured to:

Accordingly, the present specification also provides a computer apparatus comprising: a memory and a processor; the memory has stored thereon a computer program executable by the processor; the processor, when executing the computer program, performs the blockchain-based service request method performed by the service provider as described in the above embodiments.

The present specification also provides a computer device comprising: a memory and a processor; the memory has stored thereon a computer program executable by the processor; the processor, when executing the computer program, performs the blockchain-based service request method performed by the service caller as described in the above embodiments.

Accordingly, the present specification also provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs a blockchain-based service request method performed by a service provider as described in the above embodiments.

The present specification also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, performs the blockchain-based service request method performed by a service caller as described in the above embodiments.

The service request method, the device, the computer equipment or the computer readable storage medium based on the blockchain provided by the various embodiments of the specification store the secure access key and the access key ID corresponding to the service calling party in the blockchain, and the tamper-proof mechanism based on the blockchain effectively prevents the secure access key from being tampered, thereby ensuring the security of the secure access key; moreover, since the secure access key stored by the blockchain is encrypted in advance based on the public key of the service provider, only the private key party held by the service provider can decrypt the secure access key, thereby ensuring the privacy of the secure access key corresponding to the service caller.

Drawings

FIG. 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment;

FIG. 2 is a schematic diagram of a call to a smart contract provided by an exemplary embodiment;

FIG. 3 is a schematic diagram of creating a smart contract and invoking a smart contract provided by an exemplary embodiment;

FIG. 4 is a flow diagram of a blockchain-based service request method provided by an exemplary embodiment;

FIG. 5 is a schematic diagram of a blockchain-based service request device for use with a service provider in accordance with an exemplary embodiment;

FIG. 6 is a schematic diagram of a blockchain-based service request device for use with a service caller provided in an exemplary embodiment;

fig. 7 is a hardware block diagram of an embodiment of a blockchain-based service request device that is provided in the present specification.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification may be described as being broken down into multiple steps in other embodiments; while various steps described in this specification may be combined into a single step in other embodiments.

The service provider is an operator providing specific service contents for the service caller, and the service caller is a client making a service request to the service provider based on own demand. When the service provider receives a specific service call request sent by the service caller, the identity of the service caller needs to be verified.

The authentication of a service request sent by a service caller based on an access key ID and an access key pair (generally referred to as AK/SK pair) is one of the common API authentication modes on public clouds. The access key ID and access key pair corresponding to the service caller are typically generated and distributed by the service provider, and on the one hand, the service provider needs a centralized database system to store and maintain the access key ID and access key pair, and the centralized database system may be maliciously modified, which may cause the service caller to fail identity verification; on the other hand, the access key ID and the access key pair are generated by the service provider, and are usually required to be transmitted to the service caller in a network through https or the like, and the access key ID and the access key pair may be intercepted in the transmission process, which brings risks to the identity verification of the service caller.

In view of the above, one or more embodiments of the present specification provide a blockchain-based service request method for a service invocation to send a service request to a service provider.

The blockchain network in one or more embodiments of the present disclosure may specifically refer to a P2P network system with a distributed data storage structure, where each node device is implemented by a consensus mechanism, and data in the blockchain is distributed in blocks (blocks) that are temporally connected to each other, where a later block may include a data summary of a previous block, and according to a specific consensus mechanism (such as POW, POS, DPOS or PBFT, etc.), a full backup of data of all or part of nodes is implemented.

For real data generated in the physical world, the real data can be constructed into a standard transaction (transaction) format supported by a blockchain, then the transaction is issued to the blockchain, the node equipment in the blockchain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the blockchain packages the transaction into a block, and the persistence is performed in the blockchain.

Among other things, the consensus algorithm supported in the blockchain may include:

A first type of consensus algorithm, namely a consensus algorithm that node equipment needs to contend for the accounting rights of the accounting period of each round; for example, consensus algorithms such as Proof of Work (POW), proof of stock (POS), proof of commission (Delegated Proof of Stake, DPOS);

a second type of consensus algorithm, namely a consensus algorithm which pre-elects accounting nodes (without competing for accounting rights) for each round of accounting period; for example, a consensus algorithm such as the use of Bayesian fault tolerance (Practical Byzantine Fault Tolerance, PBFT) is used.

In blockchain networks employing a first type of consensus algorithm, node devices competing for accounting rights may perform a transaction after receiving the transaction. One of the node devices competing for the accounting rights may win out of the process of competing for the accounting rights in this round, becoming an accounting node. The accounting node may package the received transaction with other transactions to generate the latest chunk and send the generated latest chunk or chunks of the latest chunk to other node devices for consensus.

In blockchain networks employing a second type of consensus algorithm, node devices with accounting rights are already well-established prior to this round of accounting. Thus, after receiving a transaction, the node device may send the transaction to the billing node if it is not itself the billing node for the current round. For the billing node of the present round, the transaction may be performed during or before packaging the transaction with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or the block head of the latest block to other node devices for consensus.

As described above, regardless of which consensus algorithm is used by the blockchain as shown above, the accounting node of the round may package the received transaction to generate the latest chunk and send the generated latest chunk or chunks of the latest chunk to other node devices for consensus verification. If the other node equipment receives the latest block or the block head of the latest block, and is verified to have no problem, the latest block can be added to the end of the original blockchain, so that the accounting process of the blockchain is completed. Other nodes may also execute transactions contained in the block during the verification of the new block or block header from the accounting node.

Those skilled in the art are familiar with that, since the blockchain network system operates under the corresponding consensus mechanism, the data recorded in the blockchain database is difficult to be tampered by any node, for example, the blockchain adopting Pow consensus, and at least the attack of 51% computing power of the whole network is needed to tamper with the existing data, so that the blockchain system has the characteristics of ensuring the security and preventing the attack and tampering of the data which are incomparable with other centralized database systems. Therefore, the data recorded in the distributed database of the blockchain cannot be attacked or tampered, so that the true reliability of the data information stored in the distributed database of the blockchain is ensured.

Example types of blockchain networks may include public blockchain networks, private blockchain networks, and federated blockchain networks. Blockchains as used herein may refer to DLS (distributed ledger system) that does not refer to any particular use case.

In a common blockchain network, the consensus process is controlled by nodes of the consensus network. For example, hundreds, thousands, or even millions of entities may cooperate in a public blockchain network, each entity operating at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network with respect to participating entities.

Typically, public blockchain networks support public transactions. Public transactions are shared with all nodes within the public blockchain network and stored in the global blockchain. A global blockchain is a blockchain that replicates across all nodes. That is, for a global blockchain, all nodes are in a completely consistent state. To achieve consensus (e.g., agree to add blocks to the blockchain), a consensus protocol is implemented within the common blockchain network.

Typically, a private blockchain network is provided to a specific entity that centrally controls read and write rights. The entity controls which nodes can participate in the blockchain network. Thus, private blockchain networks are often referred to as licensed networks, which impose restrictions on who is allowed to participate in the network and its participation level (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants vote to add new entities, and a regulatory authority may control admission).

Typically, federated blockchain networks are proprietary among the participating entities. In a federated blockchain network, the consensus process is controlled by an authorized set of nodes (federated member nodes), one or more of which are operated by a corresponding entity (e.g., an enterprise). For example, a federation consisting of ten (10) entities (e.g., enterprises) can operate a federated blockchain network in which each entity operates at least one node. Thus, a federated blockchain network may be considered a private network as far as participating entities are concerned. In some examples, each entity (node) must sign each block to make the block valid and add the valid block to the blockchain. In some examples, at least a subset of entities (nodes) (e.g., at least 7 entities) must sign each block to make the block valid and add the valid block to the blockchain.

It is contemplated that the embodiments provided herein can be implemented in any suitable type of blockchain network.

In practical applications, whether public, private or federated, it is possible to provide Smart contract (Smart contract) functionality. Intelligent contracts on a blockchain are contracts on a blockchain that can be executed by a transaction trigger. The smart contracts may be defined in the form of codes.

Taking the ethernet as an example, a user is supported to create and invoke some complex logic in the ethernet network. The ethernet is used as a programmable blockchain, and the core of the ethernet is an Ethernet Virtual Machine (EVM), and each ethernet node can run the EVM. EVM is a graphics-based virtual machine through which various complex logic can be implemented. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In fact, the EVM runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"), so the smart contract deployed on the blockchain may be bytecode.

As shown in fig. 1, bob sends a Transaction (Transaction) containing information to create a smart contract to the ethernet network, and each node may execute the Transaction in the EVM. The From field of the transaction is used for recording an address of an account initiating creation of the intelligent contract, the contract code stored by the field value of the Data field of the transaction can be a byte code, and the field value of the To field of the transaction is an account null. After agreement is reached between nodes through the consensus mechanism, the intelligent contract is successfully created, and the subsequent user can call the intelligent contract.

After the intelligent contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address; for example, "0x68e12cf284 …" in each node in FIG. 1 represents the address of this contract account created; the contract Code (Code) and the account store (Storage) will be saved in the account store of the contract account. The behavior of the smart contract is controlled by the contract code, and the account store of the smart contract maintains the state of the contract. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes the contract code and account store.

The foregoing mentions that the Data field containing the transaction that created the smart contract holds may be the bytecode of the smart contract. Bytecode consists of a series of bytes, each of which can identify an operation. Based on various aspects of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. For example, a high-level language such as Solidity, serpent, LLL language may be employed. For smart contract code written in a high-level language, it may be compiled by a compiler to generate bytecodes that may be deployed onto a blockchain.

Taking the Solidity language as an example, the contract code written by the method is similar to the Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events and the like can be declared in one contract. The state variable is a value permanently stored in an account store (Storage) field of the smart contract for saving the state of the contract.

Still taking the ethernet as an example, as shown in fig. 2, bob sends a transaction containing the call intelligent contract information to the ethernet network, and each node can execute the transaction in the EVM. The From field of the transaction is used for recording the address of an account initiating the calling of the intelligent contract, the To field is used for recording the address of the called intelligent contract, and the Data field of the transaction is used for recording the method and parameters for calling the intelligent contract. After invoking the smart contract, the account status of the contract account may change. Subsequently, a client can check the account state of the contract account through the accessed blockchain node.

The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored on the blockchain, so that when the transaction is executed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating a smart contract and invoking a smart contract is shown in fig. 3. To create an intelligent contract in the ethernet, the intelligent contract needs to be written, changed into byte codes, deployed to a blockchain and the like. The intelligent contract is called in the Ethernet, a transaction pointing to the intelligent contract address is initiated, EVM of each node can execute the transaction respectively, and intelligent contract codes are distributed and run in the virtual machine of each node in the Ethernet network.

In one or more embodiments provided in the present disclosure, a terminal device corresponding to the service caller or the service provider may be used as a node device of the blockchain network described in each embodiment; the system can also be a blockchain client connected with the node equipment in the blockchain network, or can be an under-chain terminal equipment or a server connected with the node equipment in the blockchain network, and the data can be distributed to or acquired from the blockchain through data communication transmission with the node equipment in the blockchain network. For brevity, the description below uses "service invoker" to represent an offline terminal used by a service invoker, or a service invoker node device or a service invoker blockchain client, and uses "service provider" to represent an offline server terminal used by a service provider, or a service provider node device or a service provider blockchain client, and executes the blockchain-based service request method described in each embodiment.

Fig. 4 illustrates the steps of a block chain based service request method according to an exemplary embodiment of the present disclosure, including:

in step 402, the service caller generates a secure access key and a corresponding access key ID.

In this embodiment, the access key ID and the secure access key pair (i.e., AK/SK pair) may be locally generated by the service caller, so as to avoid the risk of leakage or tampering of the secure access key caused by the generation and transmission of the access key ID and the secure access key pair (i.e., AK/SK pair) by the service provider in the conventional manner.

In step 404, the service caller encrypts the secure access key based on the public key of the service provider.

The service provider may generate a public key-private key pair (public key-secret key pair) based on an asymmetric encryption algorithm and disclose its public key, and the specific disclosure manner is not limited to receiving an identity certificate transmitted by the service provider when each service caller runs a service registration procedure, or publishing its public key as public information in public, and so on. The service caller may Encrypt its generated secure access key SK using the public key of the service provider, such as generating Encrypt SK.

The various embodiments of the present description are not limited to the asymmetric encryption algorithm used by the service provider to generate the public-private key pair, e.g., RSA algorithm, ECC algorithm, etc. may be used.

And step 406, the service calling party sends the encrypted secure access key and the access key ID to the blockchain so that the encrypted secure access key and the access key ID are commonly identified and verified by node equipment of the blockchain and then stored in the blockchain.

When the service caller directly serves as the node device of the blockchain system, the service caller can package the encrypted secure access key (encryptedSK) and the corresponding access key ID (AK) into a transaction format, and broadcast the transaction to the node device of the blockchain, so that the transaction is stored in the blockchain after being identified and verified by the node device of the blockchain. When the service caller is not directly used as the node device of the blockchain system but is used as the terminal device in communication connection with the node device, the encrypted security access key (encrypt_sk) and the corresponding access key ID (AK) can be transmitted to the node device of the blockchain system, and the encrypt_sk and AK are packaged into a transaction format by the node device to upload the blockchain. The present specification has briefly described common consensus algorithms in blockchain networks as previously described, and is not limited to such consensus algorithms for blockchain networks.

In this embodiment, the service caller stores the encrypted secure access key (encrypt_sk) and the corresponding access key ID (AK) in the blockchain, and the tamper-proof mechanism based on the blockchain can effectively prevent the encrypt_sk and the corresponding AK from being tampered; and the security access key SK of the service calling party is stored in the blockchain in an encrypted state, so that the privacy of the security access key SK is further protected, and the security of the service calling party for calling the service is improved.

In a blockchain network system (such as ethernet blockchain, super-ledger, etc.) in account mode, the storage space of the blockchain includes storage spaces corresponding to account models such as user accounts and smart contract accounts in addition to BLOCKS (BLOCKS). Accordingly, storing the encrypt_sk and the corresponding access key ID in the blockchain as described in this embodiment may include storing the encrypt_sk and the corresponding access key ID in a block (block) of the blockchain, or may include storing the encrypt_sk and the corresponding access key ID in a storage space corresponding to an account model, for example, a storage space of a smart contract account.

In yet another illustrated embodiment, the blockchain has disposed thereon a smart contract for managing secure access keys; processing logic corresponding to a contract code in the intelligent contract comprises key issuing logic; the above process of sending the encrypted secure access key and the access key ID to the blockchain so that the encrypted secure access key and the access key ID are commonly authenticated by a node device of the blockchain and then stored in the blockchain may specifically include the following steps:

A service caller constructs a key issuing call transaction, wherein the key issuing call transaction comprises the encrypted security access key (encrypt_SK) and the access key ID (AK);

issuing the key issuing call transaction to a blockchain network, so that node equipment in the blockchain network responds to the key issuing call transaction, invoking the key issuing logic in the intelligent contract, and storing the secure access key (encrypt_SK) and the corresponding access key ID (AK) in an account storage space of a contract account corresponding to the intelligent contract.

The key issuing call transaction may further include a blockchain address of the smart contract, a function name of key issuing logic, interface information, and the like; the calling process of the intelligent contract has been discussed in detail before this specification, and will not be described in detail here. Compared with the implementation mode that the encrypt_SK and the corresponding AK are stored in the Block (BLOCKS) in the form of transaction, the intelligent contract is used for storing the encrypt_SK and the corresponding AK in the storage space of the contract account, so that the service provider can manage the security access keys of a plurality of service invokers more conveniently. The service provider can be used as the issuing and deploying party of the intelligent contract, and the corresponding key management mode is completed by setting corresponding key issuing logic for the intelligent contract.

In still another illustrated embodiment, the specific process of storing the secure access key and the corresponding access key ID in the account storage space of the contract account corresponding to the smart contract according to the above-described key issuing logic statement may include:

if yes, sending out a key release failure prompt;

In a blockchain network system based on an account model, such as an ethernet blockchain system, transaction trees and receipt trees corresponding to the blocks are maintained locally at node equipment (in the ethernet blockchain system, a state tree corresponding to an account global state is also maintained locally at the node equipment). The result of the smart contract running key issuing logic (including key issuing failure prompt, key storing success prompt, key storing address, etc.) is written into the transaction log of the blockchain, and the transaction log or the code value of the transaction log can be recorded into a receipt tree (recirculate tree) of the blockchain. The service caller may obtain the results of the key issuing logic recorded in the transaction log by listening to the blockchain receipt tree.

Through the processing procedure, the collision repetition of the access key ID (AK) generated by the service calling party can be effectively prevented, and if a plurality of service calling parties generate the same access key ID or the access key IDs generated by one service calling party for a plurality of times are the same, each access key ID is ensured to only correspond to one service calling party, thereby facilitating key management and identity verification.

Step 408, the service call sends a service request to the service provider; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameter based on the secure access key.

The request parameters sent by the service caller may include one or more of a request service content parameter, or a service type parameter, or a call-in parameter, or a call interface, etc. to facilitate the service provider to perform a service request based on the request parameters.

It should be noted that the first digital signature is obtained by the service caller digitally signing at least the request parameter based on the secure access key, and those skilled in the art may also digitally sign the request parameter and other technical or business parameters in the above process, which is not limited herein.

In step 410, the service provider receives the service request sent by the service caller.

At step 412, the service provider queries a corresponding encrypted secure access key based on the access key ID.

The specific process of the service provider inquiring the corresponding encrypted secure access key based on the access key ID is different based on the difference between the access key ID and the space in which the encrypted secure access key is stored.

In an illustrated embodiment, when the access key ID and the encrypted secure access key are stored in a blockchain (including an account storage space maintained locally by a block or node device), a service provider may query the access key ID and the encrypted secure access key pair as or in connection with the node device of the blockchain based on the access key ID and a storage address (e.g., txhash) of the encrypted secure access key.

In yet another illustrated embodiment, when the blockchain network is deployed with a smart contract for managing secure access keys, the access key ID and the encrypted secure access key are stored in the blockchain (including the account memory space maintained locally by the blockks or node device, such as the account space of the smart contract) by the invocation of the smart contract by the key issuing invocation transaction described in the above embodiment, since the execution result of the key issuing invocation transaction may include the access key ID and the encrypted secure access key address (such as the transaction hash value or the smart contract address); processing logic corresponding to a contract code in the smart contract may include key query logic; accordingly, the specific process of querying the corresponding encrypted secure access key based on the access key ID may include the following steps:

In a blockchain network system based on an account model, such as an ethernet blockchain system, transaction trees and receipt trees corresponding to the blocks are maintained locally at node equipment (in the ethernet blockchain system, a state tree corresponding to an account global state is also maintained locally at the node equipment). The result of the execution of the key lookup logic by the smart contract is stored in a transaction log corresponding to the smart contract invocation transaction, and the transaction log (which may be encoded in a preset code, such as rlp code) is stored in a receipt tree (receipts tree) in the form of a transaction receipt. The service provider can obtain the result of the intelligent contract inquiring the corresponding encrypted security access key based on the access key ID by monitoring the receipt tree maintained locally.

In still another illustrated embodiment, when the access key ID and the encrypted secure access key are stored in the account storage space of the smart contract for managing the secure access key, that is, when the access key ID and the encrypted secure access key are stored in the account storage space of the smart contract based on a key issuing call transaction transmitted by a service caller, the processing logic corresponding to the contract code in the smart contract may include key inquiry logic in addition to the key issuing logic; accordingly, the specific process of querying the corresponding encrypted secure access key based on the access key ID may include the following steps:

issuing the intelligent contract calling transaction to a blockchain network, so that node equipment in the blockchain network responds to the intelligent contract calling transaction, calling the key inquiry logic in the intelligent contract, and inquiring the corresponding encrypted security access key in an account storage space of a contract account corresponding to the intelligent contract based on the access key ID.

The smart contract invocation transaction may include a function name and an interface address corresponding to key lookup logic to complete invocation of the key lookup logic.

In a blockchain network system based on an account model, such as an ethernet blockchain system, transaction trees and receipt trees corresponding to the blocks are maintained locally at node equipment (in the ethernet blockchain system, a state tree corresponding to an account global state is also maintained locally at the node equipment). The result of the key lookup logic performed by the smart contract in the memory space of the contract account is stored in a transaction log corresponding to the smart contract call transaction, and the transaction log (which may be encoded by a predetermined code, such as rlp) is stored in a receipt tree (receipts tree) as a transaction receipt. The service provider can obtain the result of the intelligent contract inquiring the corresponding encrypted security access key based on the access key ID by monitoring the receipt tree maintained locally.

In step 414, the service provider decrypts the secure access key based on the private key of the service caller, and verifies the first digital signature based on the decrypted secure access key.

After the service provider obtains the secure access key corresponding to the service caller, the service provider can decrypt the secure access key corresponding to the service caller locally at the terminal of the service provider, and verify the first digital signature based on the decrypted secure access key. There may be various methods for verifying the first digital signature, and in one embodiment, the above process of verifying the first digital signature based on the decrypted secure access key may specifically include the following steps:

The above-mentioned process of decrypting the secure access key based on the private key of the service caller and verifying the first digital signature based on the decrypted secure access key may also be performed by invoking a transaction by a smart contract to further invoke digital signature verification logic of the above-mentioned smart contract. Specifically, the processing logic corresponding to the contract code in the intelligent contract further comprises digital signature verification logic; the smart contract invoking transaction may further include a function name and an interface address corresponding to the digital signature verification logic to complete the invocation of the digital signature verification logic.

The decrypting the secure access key based on the private key of the service caller and verifying the first digital signature based on the decrypted secure access key includes: and after inquiring the corresponding encrypted secure access key based on the access key ID, further calling the digital signature verification logic in the intelligent contract, decrypting the secure access key based on the private key of the service calling party, and verifying the first digital signature based on the decrypted secure access key.

It should be noted that, since the private key of the service provider is important data related to the privacy of the service provider and the security of the service information, it is generally required that the above-mentioned process of decrypting the secure access key based on the private key of the service caller and verifying the first digital signature based on the decrypted secure access key is performed in a secure computing environment. Deploying the private key of the service provider and the logical code of the smart contract in a Trusted Execution Environment (TEE) may enable secure private decryption of the secure access key and verification of the first digital signature.

In step 416, the service provider performs the service request based on the request parameters when the first digital signature is verified.

Because node devices on the blockchain can initiate call transactions to intelligent contracts deployed on the blockchain, further, security access key management for standardizing service invokers can be performed to prevent malicious attacks on the intelligent contracts, and authority control logic can be further set for the intelligent contracts to limit that only invokers of service providers can execute the key inquiry logic. In an illustrated embodiment, the smart contract executable processing logic further includes, prior to further invoking the key lookup logic in the smart contract: verifying whether the sender of the intelligent contract invoking transaction is the service provider; if so, the key query logic in the smart contract is further invoked.

There may be various specific ways of verifying whether the sender of the smart contract invocation transaction is the service provider, and in an illustrated embodiment, the smart contract invocation transaction further includes an identification ID of the service provider; the verifying whether the sender of the smart contract invocation transaction is the service provider comprises: inquiring whether the identification ID of the service provider belongs to a key inquiry authority white list stored in the intelligent contract; if so, the sender of the verification transaction is the service provider.

The intelligent contract states that there is a series of executable program code executable on the EVM of the blockchain node device. Because the intelligent contract is tracked on the blockchain after being deployed to the blockchain, the node equipment of the blockchain network has lower human intervention risk and decentralization authority characteristics, can accurately execute and achieve the consensus executing result, and can obtain more fair, fair and accurate executing result by calling key inquiry or electronic signature verification executed by the intelligent contract compared with a centralized executable program provided by a service provider possibly interfered by human.

Corresponding to the above-described flow implementation, embodiments of the present disclosure also provide for the blockchain-based service requesting devices 50 and 60. The devices 50 and 60 may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions into a memory through a CPU (Central Process Unit, central processing unit) of the device. In addition to the CPU, the memory, and the storage shown in fig. 7, the device in which the above apparatus is located generally includes other hardware such as a chip for performing wireless signal transmission and reception, and/or other hardware such as a board card for implementing a network communication function.

As shown in fig. 5, the present specification also provides a block chain-based service requesting apparatus 50 storing a secure access key generated by a service caller and a corresponding access key ID; the secure access key stored by the blockchain is encrypted in advance based on a public key of a service provider; the apparatus 50 is applied to the service provider, including:

a receiving unit 502, configured to receive a service request sent by the service caller; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameter based on the secure access key;

a querying unit 504 configured to query a corresponding encrypted secure access key based on the access key ID;

a verification unit 506 that decrypts the secure access key based on the private key of the service caller, and verifies the first digital signature based on the decrypted secure access key;

and an execution unit 508 that executes the service request based on the request parameter when the first digital signature is verified.

The query unit 504 is further configured to:

the verification unit 506 is further configured to:

In yet another illustrated embodiment, the verification unit 506 is further configured to, prior to further invoking the key lookup logic in the smart contract:

The implementation process of the functions and roles of each unit in the apparatus 50 is specifically described in detail in the implementation process of the corresponding steps in the blockchain-based service request method executed by the blockchain service provider, and the relevant points are referred to in the description of the method embodiments, and are not repeated herein.

As shown in fig. 6, the present specification further provides a service request device 60 based on a blockchain, configured to send a service request to a service provider by a service calling party, where the device 60 is applied to the service calling party, and includes:

a generating unit 602 that generates a secure access key and a corresponding access key ID, and encrypts the secure access key based on a public key of the service provider;

a transmitting unit 604 configured to transmit the encrypted secure access key and the access key ID to the blockchain, so that the encrypted secure access key and the access key ID are stored in the blockchain after being authenticated by a node device of the blockchain;

the sending unit 604 is further configured to: sending a service request to the service provider; the service request comprises a request parameter, the access key ID and a first digital signature obtained by carrying out digital signature processing on the request parameter based on the secure access key, so that the service calling party inquires a corresponding encrypted secure access key based on the access key ID, decrypts the secure access key based on a private key of the service calling party, verifies the first digital signature based on the decrypted secure access key, and executes the service request based on the request parameter when the first digital signature is verified to pass.

the sending unit 602 is further configured to:

The implementation process of the functions and roles of each unit in the above apparatus 60 is specifically described in detail in the implementation process of the corresponding steps in the blockchain-based service request method executed by the service caller of the blockchain, and the relevant points are only required to refer to part of the description of the method implementation manner, and are not repeated herein.

The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical modules, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the units or modules may be selected according to actual needs to achieve the purposes of the present description. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

The apparatus, units, and modules illustrated in the above embodiments may be implemented by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

Corresponding to the above method embodiment, the embodiment of the present specification further provides a computer device, as shown in fig. 7, where the computer device includes a memory and a processor. Wherein the memory has stored thereon a computer program executable by the processor; the processor, when executing the stored computer program, performs the steps of the blockchain-based service request method performed by the service provider in the embodiments described above. For a detailed description of the steps of the blockchain-based service request method performed by the service provider, please refer to the previous contents, and is not repeated.

Corresponding to the above method embodiment, the embodiment of the present specification further provides a computer device, as shown in fig. 7, where the computer device includes a memory and a processor. Wherein the memory has stored thereon a computer program executable by the processor; the processor, when executing the stored computer program, performs the steps of the blockchain-based service request method performed by the service invoker in the embodiments of the present description. For a detailed description of the steps of the blockchain-based service request method performed by the service caller, please refer to the previous contents, and is not repeated.

Corresponding to the above method embodiments, embodiments of the present description also provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the blockchain-based service request method performed by the service provider in the embodiments of the present description. For a detailed description of the steps of the blockchain-based service request method performed by the service provider, please refer to the previous contents, and is not repeated.

Corresponding to the above method embodiments, embodiments of the present description further provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the blockchain based service request method performed by the service caller in the embodiments of the present description. For a detailed description of the steps of the blockchain-based service request method performed by the service caller, please refer to the previous contents, and is not repeated.

The foregoing description of the preferred embodiments is provided for the purpose of illustration only, and is not intended to limit the scope of the disclosure, since any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the disclosure are intended to be included within the scope of the disclosure.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data.

Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (trans itory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

It will be appreciated by those skilled in the art that embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, embodiments of the present description may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

Claims

1. A blockchain-based service request method, the blockchain storing a secure access key and a corresponding access key ID generated by a service caller; wherein the secure access key is encrypted in advance based on a public key of a service provider; the method is applied to the service provider and comprises the following steps:

receiving a service request sent by the service calling party; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on at least the request parameter based on the secure access key;

querying the blockchain for a corresponding encrypted secure access key based on the access key ID;

decrypting the secure access key and verifying the first digital signature based on the decrypted secure access key;

2. The method of claim 1, the blockchain having disposed thereon a smart contract for managing secure access keys; processing logic corresponding to a contract code in the intelligent contract comprises key inquiry logic;

invoking the key querying logic in the smart contract to query the blockchain for an encrypted secure access key corresponding to the access key ID.

3. The method of claim 2, the secure access key and corresponding access key ID generated based on a key issuing call transaction triggered by the service caller, invoking key issuing logic of the smart contract statement, and stored in an account storage space of a contract account corresponding to the smart contract;

the querying the blockchain for the encrypted secure access key corresponding to the access key ID includes:

and inquiring the encrypted security access key corresponding to the access key ID in the account storage space of the contract account corresponding to the intelligent contract.

4. The method of claim 2 or 3, the processing logic corresponding to a contract code in the smart contract further comprising digital signature verification logic;

Decrypting the secure access key based on the private key of the service caller and verifying the first digital signature based on the decrypted secure access key, comprising:

5. The method of claim 1, the verifying the first digital signature based on the decrypted secure access key comprising:

6. The method of claim 2 or 3, further comprising, prior to further executing the key lookup logic in the smart contract:

7. The method of claim 6, the smart contract invocation transaction further comprising an identification ID of the service provider; the verifying whether the sender of the smart contract invocation transaction is the service provider comprises:

if so, confirming that the sender of the smart contract call transaction is the service provider.

8. A blockchain-based service request method for a service invoker to send a service request to a service provider, the method being applied to the service invoker and comprising:

generating a secure access key and a corresponding access key ID, and encrypting the secure access key based on a public key of the service provider;

sending a service request to the service provider; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameter based on the secure access key.

9. The method of claim 8, the blockchain having disposed thereon a smart contract for managing secure access keys; processing logic corresponding to a contract code in the intelligent contract comprises key issuing logic;

the sending the secure access key to be encrypted and the access key ID to the blockchain includes:

issuing the key issuing call transaction to a blockchain network to call the key issuing logic in the intelligent contract by node equipment in the blockchain network in response to the key issuing call transaction, and storing the encrypted secure access key and the corresponding access key ID in the blockchain.

10. The method of claim 9, the storing the secure access key to be encrypted and the corresponding access key ID in the blockchain, comprising:

and storing the encrypted secure access key and the corresponding access key ID in an account storage space of a contract account corresponding to the intelligent contract.

11. The method of claim 10, the storing the cryptographically processed secure access key and corresponding access key ID in an account memory space of a contract account corresponding to the smart contract, comprising:

12. A blockchain-based service request device, the blockchain storing a secure access key and a corresponding access key ID generated by a service caller; wherein the secure access key is encrypted in advance based on a public key of a service provider; the apparatus is applied to the service provider, and comprises:

a receiving unit for receiving a service request sent by the service calling party; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on at least the request parameter based on the secure access key;

a query unit configured to query the blockchain for a corresponding encrypted secure access key based on the access key ID;

A verification unit decrypting the secure access key and verifying the first digital signature based on the decrypted secure access key;

13. The apparatus of claim 12, the blockchain having disposed thereon a smart contract for managing secure access keys; processing logic corresponding to a contract code in the intelligent contract comprises key inquiry logic;

the query unit is further used for constructing intelligent contract calling transaction; wherein the smart contract invoking transaction includes the access key ID, invokes the key querying logic in the smart contract, and queries the blockchain for an encrypted secure access key corresponding to the access key ID based on the access key ID.

14. The apparatus of claim 13, the secure access key and corresponding access key ID generated based on a key issuing call transaction triggered by the service caller, invoking key issuing logic of the smart contract statement, and stored in an account storage space of a contract account corresponding to the smart contract;

15. The apparatus of claim 13 or 14, the processing logic of the smart contract corresponding to a contract code further comprising digital signature verification logic;

the verification unit is further configured to:

16. The apparatus of claim 12, the authentication unit further to:

17. The apparatus of claim 13 or 14, the verification unit to further verify whether a sender of the smart contract invocation transaction is a service provider prior to further executing the key lookup logic in the smart contract; if so, the key query logic in the smart contract is further invoked.

18. The apparatus of claim 17, the smart contract invocation transaction further comprising an identification ID of the service provider; the verifying whether the sender of the smart contract invocation transaction is the service provider comprises:

19. A blockchain-based service request device for a service invocation to send a service request to a service provider, the device being applied to the service invocation, comprising:

the sending unit is used for further sending a service request to the service provider; the service request comprises a request parameter, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameter based on the secure access key.

20. The apparatus of claim 19, the blockchain having disposed thereon a smart contract for managing secure access keys; processing logic corresponding to a contract code in the intelligent contract comprises key issuing logic;

the sending unit is further used for constructing a key issuing and calling transaction, and the key issuing and calling transaction comprises the encrypted security access key and the access key ID; and issuing the key issuing call transaction to a blockchain network to call the key issuing logic in the intelligent contract by node equipment in the blockchain network in response to the key issuing call transaction, and storing the encrypted secure access key and the corresponding access key ID in the blockchain.

21. The apparatus of claim 20, the secure access key to be cryptographically processed and a corresponding access key ID stored in the blockchain, comprising:

22. The apparatus of claim 21, the secure access key to be cryptographically processed and the corresponding access key ID to be stored in an account memory space of a contract account corresponding to the smart contract, comprising:

23. A computer device, comprising: a memory and a processor; the memory has stored thereon a computer program executable by the processor; the processor, when running the computer program, performs the method of any one of claims 1 to 7.

24. A computer device, comprising: a memory and a processor; the memory has stored thereon a computer program executable by the processor; the processor, when running the computer program, performs the method of any one of claims 8 to 11.

25. A computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any of claims 1 to 7.

26. A computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any of claims 8 to 11.