CN111241557A

CN111241557A - Service request method and device based on block chain

Info

Publication number: CN111241557A
Application number: CN201911421280.2A
Authority: CN
Inventors: 顾俊
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2019-12-31
Filing date: 2019-12-31
Publication date: 2020-06-05
Anticipated expiration: 2039-12-31
Also published as: CN111241557B

Abstract

The present specification provides a service request method and apparatus based on a blockchain, where the blockchain stores a secure access key and a corresponding access key ID generated by a service caller; the security 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 caller; the service request comprises a request parameter, an access key ID and a first digital signature obtained by digitally signing the request parameter based on a security access key; confirming whether the access key ID is in an unused state; if yes, inquiring a corresponding encrypted security access key based on the access key ID; decrypting the secure access key and verifying the first digital signature based on the secure access key; when the authentication is passed, the service request is executed based on the request parameter, and the access key ID is marked as used.

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 block chain technologies, and in particular, to a service request method and apparatus based on a block chain.

Background

The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. The blockchain technology has been widely used in many fields due to its characteristics of decentralization, transparency, participation of each computing device in database records, and rapid data synchronization between computing devices.

Disclosure of Invention

In view of the above, one or more embodiments of the present specification provide a service request method, apparatus, computer device and computer-readable storage medium based on a block chain.

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 and a corresponding access key ID generated by a service caller; the safe access key stored in 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 caller; the service request comprises request parameters, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameters based on the secure access key;

confirming whether the access key ID is in an unused state;

if yes, inquiring a corresponding encrypted security access key based on the access key ID;

decrypting the secure access key based on a private key of the service invoker; and verifying the first digital signature based on the decrypted secure access key; when the first digital signature is verified, the service request is executed based on the request parameters and the access key ID is marked as used.

In yet another illustrated embodiment, the service request further includes a timestamp corresponding to the secure access key generation time, the method further comprising:

checking whether the timestamp is within a preset difference range of the current time;

if so, inquiring the corresponding encrypted security access key based on the access key ID.

In yet another illustrated embodiment, a smart contract for managing security access keys is deployed on the blockchain; the security access key and the corresponding access key ID are stored in an account storage space of a contract account corresponding to the intelligent contract; the processing logic corresponding to the contract code in the intelligent contract comprises a key inquiry logic;

the confirming whether the access key ID is in an unused state, if so, inquiring a corresponding encrypted secure access key based on the access key ID, and the method comprises the following steps:

constructing a smart contract invocation transaction, wherein the smart contract invocation transaction includes the access key ID;

issuing the intelligent contract call transaction to a blockchain network, responding to the intelligent contract call transaction by a node device in the blockchain network, calling the key inquiry logic in the intelligent contract, confirming whether the access key ID is in an unused state, and inquiring a corresponding encrypted safe access key based on the access key ID if the access key ID is in an unused state.

In yet another illustrated embodiment, the smart contract invocation transaction further includes a timestamp corresponding to the secure access key generation time;

the key lookup logic further comprises:

before querying a corresponding encrypted secure access key based on the access key ID, determining whether the timestamp is within a preset difference range of the current time;

In yet another illustrated embodiment, the processing logic corresponding to the contract code in the intelligent contract further comprises 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 include:

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

In yet another illustrated embodiment, the processing logic corresponding to the contract code in the smart contract further comprises access key ID state change logic;

and after the first digital signature is verified, further calling the access key ID state change logic in the intelligent contract to mark the access key ID as a used state.

In yet another illustrative embodiment, prior to invoking the key query logic in the smart contract, further comprising:

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

In yet another illustrative embodiment, prior to invoking the access key ID state change logic in the smart contract, further comprising:

verifying whether the sender of the smart contract invocation transaction is a service provider; if so, further invoking the access key ID invalidation logic in the smart contract.

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 an authority white list stored in the intelligent contract;

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

One or more embodiments in this specification further provide a blockchain-based service request method for a service invoker to send a service request to a service provider, including:

the service caller 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;

sending the encrypted secure access key and the access key ID to the block chain, so that the encrypted secure access key and the access key ID are identified and verified by the node equipment of the block chain and then stored in the block chain;

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

In yet another illustrated embodiment, a smart contract for managing security access keys is deployed on the blockchain; the processing logic corresponding to the contract code in the intelligent contract comprises a 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 identified and verified by the node devices of the blockchain and then stored in the blockchain includes:

constructing a key issuing invoking transaction, wherein the key issuing invoking 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 invoke the key issuing logic in the intelligent contract, and storing the encrypted security access key and the corresponding access key ID in the account storage space of the contract account corresponding to the intelligent contract.

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

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

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

Correspondingly, the present specification also provides a service request device based on a blockchain, where the blockchain stores a secure access key generated by a service caller and a corresponding access key ID; the safe access key stored in the blockchain is encrypted in advance based on a public key of a service provider; the device is applied to the service provider side and comprises:

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

an inquiry unit that confirms whether the access key ID is in an unused state; if yes, inquiring a corresponding encrypted security access key based on the access key ID;

the verification unit is used for decrypting the security 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;

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

and a state changing unit for marking the access key ID as a used state.

In yet another illustrated embodiment, the service request further includes a timestamp corresponding to the secure access key generation time, and the querying unit is further configured to:

the query unit is further configured to:

the key lookup logic further comprises:

before querying a corresponding encrypted secure access key based on the access key ID, checking whether the timestamp is within a preset difference range of the current time;

the verification unit is further configured to:

and calling the digital signature verification logic in the intelligent contract, decrypting the security access key based on a private key of the service caller, and verifying the first digital signature based on the decrypted security access key.

Accordingly, the present specification further provides a service request device based on a block chain, configured to send a service request to a service provider by a service caller, where the device is applied to the service caller, and includes:

a generation unit 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 sending unit, configured to send the encrypted secure access key and the access key ID to the block chain, so that the encrypted secure access key and the access key ID are identified and verified by the node device of the block chain and then stored in the block chain;

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

the sending unit is further configured to:

Accordingly, this specification also provides a computer device comprising: a memory and a processor; the memory having stored thereon a computer program executable by the processor; the processor executes the computer program to perform the service request method based on the block chain executed by the service provider according to the embodiments.

The present specification also provides a computer device comprising: a memory and a processor; the memory having stored thereon a computer program executable by the processor; when the computer program is executed, the processor executes the service request method based on the block chain executed by the service caller according to the embodiments.

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

The present specification also provides a computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, executes the blockchain-based service request method executed by a service caller according to the embodiments described above.

In the service request method, device, computer device, or computer-readable storage medium based on the block chain provided in each embodiment of the present specification, a secure access key and an access key ID corresponding to a service caller are stored in the block chain, and based on a tamper-resistant mechanism of the block chain, the secure access key is effectively prevented from being tampered, and the security of the secure access key is ensured; moreover, since the secure access key stored in the blockchain is encrypted in advance based on the public key of the service provider, only the service provider holding the private key 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 an intelligent contract provided by an exemplary embodiment;

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

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

FIG. 4 is a flowchart illustrating a block chain based service request method according to an exemplary embodiment;

FIG. 5 is a schematic diagram of a blockchain-based service request device applied to a service provider according to an exemplary embodiment;

FIG. 6 is a block chain based service request mechanism applied to a service caller according to an exemplary embodiment;

fig. 7 is a hardware block diagram for implementing an embodiment of a block chain based service request apparatus provided in the present specification.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent 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 certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the methods may include more or less steps than those described herein. Moreover, a single step described in this specification may be divided into multiple steps for description in other embodiments; however, in other embodiments, multiple steps described in this specification may be combined into a single step for description.

The service provider is an operator providing specific service content for the service invoker, and the service invoker is a client providing a service request to the service provider based on self requirements. When receiving a specific service invocation request sent by a service invoker, a service provider needs to verify the identity of the service invoker.

The identity authentication of the service request sent by the service caller based on the access key ID and the access key pair (generally referred to as AK/SK pair) is one of the common API authentication methods in public cloud. The access key ID and the access key pair corresponding to the service invoker are usually generated and distributed by the service provider, on one hand, the service provider needs a centralized database system to store and maintain the access key ID and the access key pair, and the centralized database system may be maliciously modified, which may result in that the service invoker cannot pass identity authentication; on the other hand, the access key ID and the access key pair are generated by a service provider, and generally need to be transmitted to a service caller in a network through https or the like, and the access key ID and the access key pair may be intercepted during transmission, which brings a risk to the identity authentication 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 invoker to send a service request to a service provider.

The block chain network according to one or more embodiments of the present disclosure may specifically refer to a P2P network system having a distributed data storage structure, where each node device achieves data sharing via a common knowledge mechanism, and data in the block chain is distributed in temporally consecutive "blocks" (where a latter block may contain a data digest of a former block, and a full backup of data of all or part of nodes is achieved according to different common knowledge mechanisms (e.g., POW, POS, DPOS, PBFT, etc.).

The real data generated by the physical world can be constructed into a standard transaction (transaction) format supported by a block chain, then is issued to the block chain, the node equipment in the block chain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the block chain packs the transaction into a block and performs persistent evidence storage in the block chain.

The consensus algorithm supported in the blockchain may include:

the first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;

the second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.

In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a latest block and send the generated latest block or a block header of the latest block to other node devices for consensus.

In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current 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 a block header of the latest block to other node devices for consensus.

As described above, regardless of which consensus algorithm is adopted by the blockchain, the accounting node of the current round may pack the received transaction to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus verification. If no problem is verified after other node equipment receives the latest block or the block header of the latest block, the latest block can be added to the tail of the original block chain, so that the accounting process of the block chain is completed. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.

As is well known to those skilled in the art, since the blockchain network system operates under a corresponding consensus mechanism, data that has been recorded in the blockchain database is difficult to be tampered with by any node, for example, a blockchain with Pow consensus is adopted, and it is possible to tamper with existing data only by an attack that requires at least 51% of effort over the entire network, so the blockchain system has characteristics of ensuring data security and preventing tampering against attacks, which are incomparable with other centralized database systems. Therefore, the data recorded in the distributed database of the blockchain cannot be attacked or tampered, and the authenticity and reliability of the data information of the distributed database of the blockchain are guaranteed.

Example types of blockchain networks may include public blockchain networks, private blockchain networks, and federation blockchain networks. Although the term blockchain is typically associated with bitcoin cryptocurrency networks, blockchains as used herein may refer to DLS (distributed ledger system) that do not reference any particular use case.

In a public 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. Example public blockchain networks include bitcoin networks, which are peer-to-peer payment networks. Bitcoin networks utilize a distributed ledger, called blockchains. However, as noted above, the term blockchain is generally used to refer to distributed ledgers that do not specifically refer to bitcoin networks.

Typically, public blockchain networks support public transactions. The public transaction is shared with all nodes within the public blockchain network and stored in the global blockchain. A global blockchain is a chain of blocks that is replicated 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 a blockchain), a consensus protocol is implemented within a public blockchain network. Example consensus protocols include, but are not limited to, proof of work (POW) implemented in bitcoin networks.

Typically, a private blockchain network is provided for a particular entity that centrally controls read and write permissions. 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 level of participation (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants vote to add a new entity, and regulatory authorities may control admission).

Typically, a federated blockchain network is private among the participating entities. In a federated blockchain network, the consensus process is controlled by an authorized set of nodes (federation member nodes), one or more of which are operated by respective entities (e.g., enterprises). For example, a federation consisting of ten (10) entities (e.g., enterprises) may 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 in terms of participating entities. In some examples, each entity (node) must sign each block to validate the block and add the validated block to the blockchain. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each block to validate the block and add the validated 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 alliance, it is possible to provide the functionality of a smart contract (Smartcontract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode.

After Bob sends a Transaction (Transaction) containing information to create a smart contract to the ethernet network, each node can execute the Transaction in the EVM, as shown in fig. 1. The From field of the transaction in the figure is used for recording the address of the account initiating the creation of the intelligent contract, the contract code stored in the field value of the Data field of the transaction can be byte code, and the field value of the To field of the transaction is a null account. After the nodes reach the agreement through the consensus mechanism, the intelligent contract is successfully created, and the follow-up user can call the intelligent contract.

After the intelligent contract is established, a contract account corresponding to the intelligent contract appears on the block chain, and the block chain has a specific address; for example, "0 x68e12cf284 …" in each node in fig. 1 represents the address of the contract account created; the contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.

As mentioned above, the Data field containing the transaction that created the intelligent contract may hold the byte code of the intelligent contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations 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, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.

Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage) field of an intelligent contract to save the state of the contract.

As shown in FIG. 2, still taking the Etherhouse as an example, after Bob sends a transaction containing the information of the calling intelligent contract to the Etherhouse network, each node can execute the transaction in the EVM. The From field of the transaction in the figure is used for recording the address of the account initiating the intelligent contract calling, the To field is used for recording the address of the intelligent contract called, and the Data field of the transaction is used for recording the method and the parameters for calling the intelligent contract. After invoking the smart contract, the account status of the contract account may change. Subsequently, a certain client can check the account status of the contract account through the accessed block chain node.

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

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, the EVM of each node can respectively execute the transaction, and the intelligent contract code is distributed and operated in the virtual machine of each node in the Ethernet workshop network.

In one or more embodiments provided in this specification, the terminal device corresponding to the service caller or the service provider may be a node device of the blockchain network according to each embodiment; the system may also be a blockchain client connected to the node device in the blockchain network, or may also be a linked terminal device or a server connected to the node device in the blockchain network, and the system may transmit data to the blockchain or obtain data from the blockchain by communicating with the node device in the blockchain network. For the sake of simplicity, in the following description, a "service caller" represents an offline terminal used by the service caller, or a terminal device such as a service caller node device or a service caller blockchain client, and a "service provider" represents an offline server terminal used by the service provider, or a terminal device such as a service provider node device or a service provider blockchain client, and executes the service request method based on the blockchain according to each embodiment.

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

at step 402, the service invoker generates a secure access key and a corresponding access key ID.

In the embodiment, the access key ID and the secure access key pair (i.e., AK/SK pair) can be locally generated by the service caller, so that the risk that the secure access key is leaked or tampered in the conventional manner due to the fact that the access key ID and the secure access key pair (i.e., AK/SK pair) are generated and transmitted by the service provider is avoided.

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-secrekey pair) based on an asymmetric encryption algorithm, and publish the public key thereof, where a specific publishing manner is not limited to receiving an identity certificate transmitted by the service provider when each service caller runs a service registration program, or publishing the public key as public information, and the like. The service invoker may Encrypt the secure access key SK it generates, such as generating Encrypt _ SK, using the public key of the service provider.

The asymmetric encryption algorithm used by the service provider to generate the public-private key pair is not limited in the various embodiments of the present description, and for example, an RSA algorithm, an ECC algorithm, or the like may be used.

Step 406, the service caller sends the encrypted secure access key and the access key ID to the block chain, so that the encrypted secure access key and the access key ID are identified and verified by the node devices of the block chain and then stored in the block chain.

When the service caller directly acts as the node device of the blockchain system, the service caller may pack the encrypted secure access key (Encrypt _ SK) and the corresponding access key id (ak) into a transaction format, and then broadcast the transaction to the node device of the blockchain, so that the transaction is identified and verified by the node device of the blockchain and then stored in the blockchain. When the service caller is not directly used as the node device of the blockchain system but as a terminal device in communication connection with the node device, the encrypted secure access key (Encrypt _ SK) and the corresponding access key id (AK) may be transmitted to the node device of the blockchain system, and the Encrypt _ SK and the AK are packaged by the node device into a transaction format upload blockchain. As mentioned above, the common consensus algorithm in the blockchain is briefly described, and the consensus algorithm in the blockchain network is not limited herein.

In this embodiment, the service caller stores the encrypted secure access key (Encrypt _ SK) and the corresponding access key id (AK) in a blockchain, and based on a tamper-resistant mechanism of the blockchain, the Encrypt _ SK and the corresponding AK can be effectively prevented from being tampered; and the safe access key SK of the service calling party is stored in the block chain in an encrypted state, so that the privacy of the safe access key SK is further protected, and the safety of calling the service by the service calling party is improved.

In an account-mode blockchain network system (e.g., ethernet blockchain, hyper-leader, etc.), the storage space of the blockchain includes, in addition to BLOCKS (BLOCKS), storage spaces corresponding to account models such as user accounts and smart contract accounts. Therefore, the storing of Encrypt _ SK and the corresponding access key ID in the block chain according to this embodiment may include storing Encrypt _ SK and the corresponding access key ID in a Block (BLOCKS) of the block chain, and may also include storing 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 illustrative embodiment, a smart contract for managing a security access key is deployed on the blockchain; the processing logic corresponding to the contract code in the intelligent contract comprises a key issuing logic; the foregoing process of sending the encrypted secure access key and the access key ID to the block chain, so that the encrypted secure access key and the access key ID are identified and verified by the node device of the block chain and then stored in the block chain may specifically include the following steps:

the service caller constructs a key issuing call transaction, wherein the key issuing call transaction comprises the encrypted secure access key (Encrypt _ SK) and the access key id (ak);

issuing the key issuance call transaction to a blockchain network to invoke the key issuance logic in the smart contract by a node device in the blockchain network in response to the key issuance call transaction, storing the secure access key (Encrypt _ SK) and a corresponding access key id (ak) in an account storage space of a contract account corresponding to the smart contract.

The key issuing call transaction may further include a blockchain address of the smart contract, a function name of the key issuing logic, interface information, and the like; the calling process of the intelligent contract has been discussed in detail before this specification, and is not described in detail herein. Compared with the implementation mode that only the Encrypt _ SK and the corresponding AK are stored in the Block (BLOCKS) in the form of transaction, the Encrypt _ SK and the corresponding AK are stored in the storage space of the contract account through the intelligent contract, and 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 party of the intelligent contract, and the corresponding key management mode is completed by setting the corresponding key issuing logic for the intelligent contract.

In yet 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, which is declared by the key issuing logic, may include:

if yes, sending out a key issuing failure prompt;

In a blockchain network system based on an account model, such as an ether house blockchain system, a transaction tree and a receipt tree corresponding to a block are maintained locally at a node device (in the ether house blockchain system, a status tree corresponding to an account global status is also maintained locally at the node device). The result of the smart contract running the key issuing logic (including a key issuing failure prompt, a key storage success prompt, a key storage address, or the like) is written into a transaction log of the blockchain, and the transaction log or an encoded value of the transaction log may be recorded in a receipt tree (recipes tree) of the blockchain. The service invoker can obtain the result of the key issuing logic recorded in the transaction log by monitoring the receipt tree of the block chain.

Through the processing process, the access key ID (AK) generated by the service calling party can be effectively prevented from being repeated, 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 multiple times are the same, each access key ID is ensured to only uniquely correspond to one service calling party, and therefore key management and identity authentication are facilitated.

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

The request parameters sent by the service caller may include one or more of request service content parameters, or service type parameters, or call interfaces, etc. to facilitate the service provider to execute the 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 security access key thereof, and those skilled in the art may also obtain the first digital signature by digitally signing the request parameter and other technical or business parameters in the process from the technical or business requirements, which is not limited herein.

Step 410, the service provider receives the service request sent by the service caller.

Step 412, the service provider confirms whether the access key ID is in an unused state;

in an illustrated embodiment, the service provider may locally record an access key ID status corresponding to the service invoker, and mark an access key ID included in the service request as a used status after executing the service request sent by the service invoker each time; for a service request containing a used state access key ID, the provider will not perform its service request content any more, such as sending a denial of service notification directly to it.

By marking the use state of the access key ID and only executing the service request (or only inquiring the safe access key in the unused state) encrypted by the digital signature of the safe access key in the unused state (corresponding to the access key ID one by one), the service caller can use the new access key ID and the safe access key each time the service request is sent, and the false service request sent by the fake service caller after the service request is intercepted by other parties is prevented, so that the safety of the service system is further improved; moreover, the service mode of one-time pad can effectively prevent the service request sent by the service calling party from possibly launching malicious replay attack after being maliciously intercepted, and improves the stability of the system.

The service caller, when encrypting the request parameters to lift the service request in the manner of the one-time pad described above, typically generates an access key ID and a secure access key pair (AK/SK pair) when lifting the request parameters, in a further illustrated embodiment, the service request further comprises a timestamp corresponding to the time of generation of the secure access key (or access key ID), after the service provider receives the service request, for example, before querying a corresponding encrypted secure access key based on the access key ID, in addition to verifying whether the access key ID is in an unused state, it is also verified whether a difference between a generation time of the access key ID and a secure access key pair (AK/SK pair) and a current time is within a preset difference range, so as to further ensure synchronization between the service enabler and the service provider; or the AK/SK pair which is not consumed by the service request for a long time after being generated is subjected to failure processing, so that the safety of the system is further improved.

Step 414, if the access key ID is in an unused state, querying the corresponding encrypted secure access key based on the access key ID.

The specific process of the service provider querying 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 where 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 a locally maintained account storage space of BLOCKS or node devices), the service provider may act as or connect to a node device of the blockchain, and may query the access key ID and the encrypted secure access key pair based on the access key ID and an address (e.g., Txhash) of the encrypted secure access key.

In yet another illustrative embodiment, when a smart contract for managing a secure access key is deployed on the blockchain network, the access key ID and the cryptographically processed secure access key are stored in an account space of the smart contract through a key issuance invocation transaction of the smart contract according to the above embodiment, and processing logic corresponding to a contract code in the smart contract may include key inquiry logic; correspondingly, the specific process of determining whether the access key ID is in an unused state, and if so, querying the corresponding encrypted secure access key based on the access key ID includes:

Specifically, when the access key ID and the encrypted secure access key pair are stored in the account space of the smart contract, a corresponding status bit may be set for the access key ID or the encrypted secure access key, for example, when the status bit is "T", the access key ID is identified as an unused status, and when the status bit is "F", the access key ID is identified as a used status.

In a blockchain network system based on an account model, such as an ether house blockchain system, a transaction tree and a receipt tree corresponding to a block are maintained locally at a node device (in the ether house blockchain system, a status tree corresponding to an account global status is also maintained locally at the node device). The result of the smart contract executing the key inquiry logic is stored in a transaction log corresponding to the smart contract invocation transaction, and the transaction log (which may be encoded by a predetermined code such as rlp) is stored in a receipt tree (recipes tree) in the form of a transaction receipt. The service provider can obtain the result that the intelligent contract inquires the corresponding encrypted security access key based on the access key ID by monitoring a locally maintained receipt tree.

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

Step 416, the service provider decrypts the secure access key based on the private key of the service invoker, and verifies the first digital signature based on the decrypted secure access key.

After the service provider acquires the security access key corresponding to the service caller, the service provider can decrypt the security access key corresponding to the service caller based on the private key of the service provider locally at the terminal of the service provider, and check the first digital signature based on the decrypted security access key. There are various methods for verifying the first digital signature, and in an illustrated embodiment, the process of verifying the first digital signature based on the decrypted secure access key may specifically include the following steps:

performing digital signature on the request parameter 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, determining that the first digital signature is verified.

The above-mentioned process of decrypting the security access key based on the private key of the service invoker and verifying the first digital signature based on the decrypted security access key may also be performed by invoking a transaction by the smart contract to further invoke the digital signature verification logic of the smart contract. Specifically, the processing logic corresponding to the contract code in the intelligent contract further includes digital signature verification logic; the smart contract invocation 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 include: and after inquiring a corresponding encrypted security access key based on the access key ID, further calling the digital signature verification logic in the intelligent contract, decrypting the security access key based on a private key of the service caller, and verifying the first digital signature based on the decrypted security 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, the smart contract is usually required to execute 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 in a secure computing environment. Deploying the private key of the service provider and the logic code of the smart contract in a Trusted Execution Environment (TEE) may enable secure and private decryption of the secure access key and verification of the first digital signature.

When the first digital signature is verified, the service provider executes the service request based on the request parameter and marks the access key ID as used, step 418.

As described above, when the account space of the smart contract is provided with a status bit for identifying the use status of the access key ID (/ and the encrypted secure access key), the processing logic corresponding to the contract code in the smart contract further includes an access key ID status change logic; and after the first digital signature is verified, further calling the access key ID state change logic in the intelligent contract to mark the access key ID as a used state.

Because the node devices on the blockchain can initiate a calling transaction to the intelligent contract deployed on the blockchain, further, in order to standardize the security access key management of the service caller and prevent malicious attack on the intelligent contract, the intelligent contract can also set an authority control logic to limit the key inquiry logic to be executable only by the caller of the service provider. In an illustrative embodiment, prior to further invoking the key query logic in the smart contract, or prior to further invoking the access key ID state change logic in the smart contract, smart contract-executable processing logic further comprises: verifying whether a sender of the intelligent contract invoking transaction is the service provider; if so, further invoking the key query logic in the smart contract.

There are 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 declares a series of executable program code that may be executed on the EVM of the block-linked node device. Because the intelligent contract is deployed to the block chain, any change or change of the intelligent contract is traceable on the block chain, so that the block chain network has lower human intervention risk and decentralized authority characteristics, node devices of the block chain network can accurately execute and achieve a consensus execution result, and compared with a centralized executable program provided by a service provider which can be subjected to human intervention, a more fair, fair and accurate execution result can be obtained by calling key inquiry or electronic signature verification executed by the intelligent contract.

Corresponding to the above flow implementation, the embodiments of the present specification further provide service request devices 50 and 60 based on block chains. The means 50 and 60 may be implemented by software, by hardware or by a combination of both. Taking a software implementation as an example, the logical device is formed by reading a corresponding computer program instruction into a memory for running through a Central Processing Unit (CPU) of the device. In terms of hardware, the device in which the apparatus is located generally includes other hardware such as a chip for transmitting and receiving wireless signals and/or other hardware such as a board for implementing a network communication function, in addition to the CPU, the memory, and the storage shown in fig. 7.

As shown in fig. 5, the present specification further provides a service request apparatus 50 based on a blockchain, where the blockchain stores a secure access key and a corresponding access key ID generated by a service caller; the safe access key stored in the blockchain is encrypted in advance based on a public key of a service provider; the apparatus 50 is applied to the service provider side, and includes:

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

an inquiry unit 504 that confirms whether the access key ID is in an unused state; if yes, inquiring a corresponding encrypted security access key based on the access key ID;

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

an execution unit 508, executing the service request based on the request parameter when the first digital signature is verified;

the state change unit 510 marks the access key ID as a used state.

In yet another illustrated embodiment, the service request further includes a timestamp corresponding to the secure access key generation time, and the querying unit 504 is further configured to:

the querying unit 504 is further configured to:

the key lookup logic further comprises:

the verification unit 506 is further configured to:

The implementation process of the functions and actions of each unit in the apparatus 50 is specifically described in the implementation process of the corresponding step in the service request method based on the block chain executed by the service provider of the block chain, and related points may be referred to part of the description of the method embodiment, which is not described herein again.

As shown in fig. 6, the present specification further provides a block chain-based service request apparatus 60 for a service caller to send a service request to a service provider, where the apparatus 60 is applied to the service caller, 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 sending unit 604, configured to send the encrypted secure access key and the access key ID to the block chain, so that the encrypted secure access key and the access key ID are identified and verified by the node devices of the block chain and then stored in the block chain;

the sending unit 604 is further configured to send a service request to the service provider; the service request comprises request parameters, the access key ID and a first digital signature obtained by performing digital signature processing on the request parameters based on the security access key.

the sending unit 604 is further configured to:

The implementation process of the function and the action of each unit in the apparatus 60 is specifically detailed in the implementation process of the corresponding step in the service request method based on the block chain executed by the service caller of the block chain, and related points may be referred to part of the description of the method embodiment, which is not described herein again.

The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the units or modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.

The apparatuses, units and modules described in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging 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, including 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 described above in the embodiments of the present specification. For a detailed description of each step of the block chain based service request method performed by the service provider, please refer to the previous contents, which 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, including 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 block chain based service request method performed by the service invoker in the embodiments of the present specification. For a detailed description of each step of the block chain based service request method executed by the service caller, please refer to the previous contents, which is not repeated.

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

Corresponding to the above method embodiments, the embodiments of the present specification further provide a computer-readable storage medium, on which computer programs are stored, which, when executed by a processor, perform the steps of the block chain based service request method performed by the service caller in the embodiments of the present specification. For a detailed description of each step of the block chain based service request method executed by the service caller, please refer to the previous contents, which is not repeated.

The above description is only for the purpose of illustrating the preferred embodiments of the present disclosure and is not to be construed as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure are intended to be included within the scope of the present disclosure.

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

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

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 computer storage media 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 that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include transitory computer readable media (trans-entity 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 an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

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

Claims

1. A service request method based on a block chain, wherein the block chain stores a security access key generated by a service calling party and a corresponding access key ID; the safe access key stored in the blockchain is encrypted in advance based on a public key of a service provider; the method comprises the following steps:

confirming whether the access key ID is in an unused state;

2. The method of claim 1, the service request further comprising a timestamp corresponding to the secure access key generation time, the method further comprising:

3. The method of claim 1 or 2, the blockchain having disposed thereon a smart contract for managing a secure access key; the security access key and the corresponding access key ID are stored in an account storage space of a contract account corresponding to the intelligent contract; the processing logic corresponding to the contract code in the intelligent contract comprises a key inquiry logic;

4. The method of claim 3, the smart contract invocation transaction further comprising a timestamp corresponding to the secure access key generation time;

the key lookup logic further comprises:

5. The method of claim 3, wherein the processing logic corresponding to contract code in the intelligent contract further comprises digital signature verification logic;

6. The method of claim 3, wherein the processing logic corresponding to the contract code in the smart contract further comprises access key ID state change logic;

7. The method of claim 3, prior to invoking the key lookup logic in the smart contract, further comprising:

8. The method of claim 6, prior to invoking the access key ID state change logic in the smart contract, further comprising:

9. The method of claim 7 or 8, 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:

10. A service request method based on block chain is used for a service caller to send a service request to a service provider, and comprises the following steps:

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

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

13. A service request device based on a blockchain, wherein the blockchain stores a security access key generated by a service calling party and a corresponding access key ID; the safe access key stored in the blockchain is encrypted in advance based on a public key of a service provider; the device is applied to the service provider side and comprises:

and a state changing unit for marking the access key ID as a used state.

14. The apparatus of claim 13, the service request further comprising a timestamp corresponding to the secure access key generation time, the query unit further to:

15. The apparatus of claim 13 or 14, the blockchain having a smart contract deployed thereon for managing a secure access key; the security access key and the corresponding access key ID are stored in an account storage space of a contract account corresponding to the intelligent contract; the processing logic corresponding to the contract code in the intelligent contract comprises a key inquiry logic;

the query unit is further configured to:

16. The apparatus of claim 15, the smart contract invocation transaction further comprising a timestamp corresponding to the secure access key generation time;

the key lookup logic further comprises:

17. The apparatus of claim 15, wherein the processing logic corresponding to contract code in the intelligent contract further comprises digital signature verification logic;

the verification unit is further configured to:

18. The apparatus of claim 15, wherein the processing logic corresponding to contract code in the smart contract further comprises access key ID state change logic;

19. A service request device based on block chain, which is used for a service caller to send a service request to a service provider, and is applied to a service caller, comprising:

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

the sending unit is further configured to:

21. The apparatus of claim 20, the storing the cryptographically processed and corresponding access key ID in an account storage space of a contract account corresponding to the smart contract, comprising:

22. A computer device, comprising: a memory and a processor; the memory having stored thereon a computer program executable by the processor; the processor, when executing the computer program, performs the method of any of claims 1 to 9.

23. A computer device, comprising: a memory and a processor; the memory having stored thereon a computer program executable by the processor; the processor, when executing the computer program, performs the method of any of claims 10 to 12.

24. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 9.

25. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 10 to 12.