HK40047330B - Blockchain-based authentication method and apparatus, medium, and device - Google Patents

Description

Authentication method, device, medium and equipment based on block chain

Technical Field

The present disclosure relates to the field of block chain technologies, and in particular, to an authentication method, apparatus, medium, and device based on a block chain.

Background

In order to prevent malicious request access from occupying network resources, the backend server typically authenticates relevant parameters (e.g., application package name, channel ID, GUID, device MAC address) when the client requests access, so as to verify the validity of the client access. Before requesting data from the server, each client needs to pass authentication of the background server, and can acquire data fed back by the server after passing authentication. In this way, the dependence on the background server is strong, and if the background server is down, the problem that the authentication cannot be timely or correctly performed is easily caused. In addition, the centralized background server also has a problem of low efficiency in responding to each authentication request, so how to reduce the authentication times on the premise of ensuring security and avoid the waste of computing resources also becomes a problem to be solved at present.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The invention aims to provide a block link-based authentication method, a block link-based authentication device, a computer-readable storage medium and an electronic device, and by implementing the embodiment of the invention, the uniqueness, the non-tampering property and the reliability of a decentralized block link network can be utilized, and after receiving an authentication request, the authentication request is verified, identified and written, so that on one hand, the legality and the privacy of the authentication request are ensured, on the other hand, the problem that the authentication cannot be timely performed after a background server is down in the prior art is solved by utilizing the advantage of block link distributed storage, and on the other hand, the current user can be enabled to have legality within the personalized authentication effective duration by performing time monitoring on the authentication request, so that the number of authentication times is reduced on the premise of ensuring the security, and the waste of computing resources is avoided.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

According to an aspect of the present disclosure, there is provided an authentication method based on a block chain, including:

when receiving the authentication request, carrying out validity verification on the authentication request;

if the authentication request is verified to be legal, performing consensus on the authentication request and writing the authentication request into a block chain account book;

requesting response data from the server according to the writing result, and responding to the authentication request according to the response data;

determining the authentication level corresponding to the current user according to the user identification extracted from the authentication request, and calling an intelligent contract so that the intelligent contract carries out time-efficiency monitoring on the authentication request according to the authentication effective duration corresponding to the authentication level;

when the expiration of the authentication valid duration is detected, generating a failure voucher for representing the failure of the authentication request, and writing the failure voucher into a block chain account book; wherein, the invalid authentication request can not prove the validity of the current user.

According to an aspect of the present disclosure, there is provided an authentication apparatus based on a block chain, including:

the request verification unit is used for verifying the legality of the authentication request when receiving the authentication request;

the request consensus unit is used for performing consensus on the authentication request and writing the authentication request into a block chain account book when the validity of the authentication request is verified;

the request response unit is used for requesting response data from the server according to the writing result and responding the authentication request according to the response data;

the time efficiency monitoring unit is used for determining the authentication level corresponding to the current user according to the user identification extracted from the authentication request and calling the intelligent contract so that the intelligent contract carries out time efficiency monitoring on the authentication request according to the authentication effective duration corresponding to the authentication level;

the system comprises a failure information uplink unit, a block chain account book and a block chain management unit, wherein the failure information uplink unit is used for generating a failure certificate for representing failure of an authentication request when detecting that the effective authentication duration expires, and writing the failure certificate into the block chain account book; wherein, the invalid authentication request can not prove the validity of the current user.

In an exemplary embodiment of the present disclosure, the determining, by the aging monitoring unit, an authentication level corresponding to a current user according to a user identifier extracted from an authentication request includes:

extracting a user identifier corresponding to the current user from the authentication request;

determining a target block in a block chain account book for recording each user grade;

and reading the authentication level corresponding to the user identification from the Mercker tree of the target block.

In an exemplary embodiment of the present disclosure, the aging monitoring unit invokes the intelligent contract, so that after the intelligent contract performs aging monitoring on the authentication request according to the authentication valid duration corresponding to the authentication level, and before the chain unit detects that the authentication valid duration expires, the method further includes:

the detection unit is used for detecting whether a block corresponding to the secondary authentication request exists in the block chain account book or not when the secondary authentication request corresponding to the current user is received;

and the request response unit is further used for requesting secondary response data from the server and feeding back the secondary response data to the client of the secondary authentication request after the detection unit detects that the block corresponding to the secondary authentication request exists in the block chain ledger.

In an exemplary embodiment of the present disclosure, the invoking, by the aging monitoring unit, an intelligent contract to enable the intelligent contract to perform aging monitoring on the authentication request according to the authentication valid duration corresponding to the authentication level includes:

starting to perform time-efficiency monitoring on the authentication request after responding to the authentication request;

if the authentication effective duration corresponding to the authentication level is not expired and the client for receiving the response data stops receiving the data, determining the data transmission duration;

and calling an intelligent contract to calculate a target fee for the data transmission duration and deducting the target fee from the account of the current user.

In an exemplary embodiment of the present disclosure, the requesting and consensus unit performs consensus on the authentication request, including:

and inquiring whether a branch node corresponding to the authentication request exists in the Mercker tree of the block chain account book, and if not, identifying the authentication request.

In an exemplary embodiment of the present disclosure, further comprising:

the node determining unit is used for determining a branch node corresponding to the authentication request from the Mercker tree after the request consensus unit writes the authentication request into the block chain account book;

and the node feedback unit is used for feeding back the branch nodes to the client side sending the authentication request.

In an exemplary embodiment of the present disclosure, after the node feedback unit feeds back the branch node to the client sending the authentication request, the client generates a new authentication request according to the authentication digest in the branch node, and sends the new authentication request to the background server.

In an exemplary embodiment of the present disclosure, the requesting the response unit to request the response data from the server according to the write result includes:

and judging that the authentication request passes the authentication according to the writing result, and sending a multimedia file request to the server so that the server feeds back the corresponding multimedia file as response data according to the request content corresponding to the authentication request.

In an exemplary embodiment of the present disclosure, the requesting response unit responds to the authentication request according to the response data, including:

and feeding back the multimedia file to the client sending the authentication request so that the client renders the content to be displayed according to the multimedia file.

In an exemplary embodiment of the present disclosure, the requesting and identifying unit identifies the authentication request and writes the authentication request into the block chain ledger, including:

the authentication request is identified through an identification node and written into a block chain account book; the ratio between the number of the common nodes and the total number of the nodes in the block chain is within a preset range.

In an exemplary embodiment of the present disclosure, the requesting consensus unit performs consensus on the authentication request through the consensus node and writes the authentication request into the block chain ledger, including:

broadcasting the authentication request so that each consensus node calculates an authentication digest of the block to which the authentication request belongs:

determining a consensus result according to the consistency of the authentication abstract calculated by each consensus node;

and if the consensus result accords with the preset result, writing the block into a block chain account book.

In an exemplary embodiment of the present disclosure, before determining the authentication level corresponding to the current user according to the user identifier extracted from the authentication request, the method further includes:

acquiring a recharging record corresponding to the current user, and determining an authentication level corresponding to the current user according to the recharging record;

the authentication level corresponding to the current user is changed along with the change of the recharging record corresponding to the current user, and the authentication level corresponding to the current user is positively correlated with the authentication effective duration corresponding to the current user.

According to an aspect of the present application, there is provided an electronic device including: a processor; and a memory for storing executable instructions for the processor; wherein the processor is configured to perform the method of any of the above via execution of the executable instructions.

According to an aspect of the application, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any one of the above.

According to an aspect of the application, a computer program product or computer program is provided, comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method provided in the various alternative implementations described above.

The exemplary embodiments of the present application may have some or all of the following advantages:

in the block chain-based authentication method provided in an exemplary embodiment of the present application, when an authentication request is received, the validity of the authentication request may be verified; if the authentication request is verified to be legal, performing consensus on the authentication request and writing the authentication request into a block chain account book; requesting response data from the server according to the writing result, and responding to the authentication request according to the response data; determining the authentication level corresponding to the current user according to the user identification extracted from the authentication request, and calling an intelligent contract so that the intelligent contract carries out time-efficiency monitoring on the authentication request according to the authentication effective duration corresponding to the authentication level; when the expiration of the authentication valid duration is detected, generating a failure voucher for representing the failure of the authentication request, and writing the failure voucher into a block chain account book; wherein, the invalid authentication request can not prove the validity of the current user. According to the scheme description, on one hand, the uniqueness, the non-tampering property and the reliability of the decentralized block link network can be utilized, and after the authentication request is received, the authentication request is verified, identified and written, so that the legality and the privacy of the authentication request are ensured, and the malicious authentication request is prevented from attacking a background server. In another aspect of the present application, the advantage of the block chain distributed storage can be utilized, the problem that the authentication cannot be performed in time after the shutdown of the background server in the prior art is solved, and the stability of the authentication process is improved. On the other hand, the method and the device can enable the current user to have legality within the personalized authentication valid duration by performing time-dependent monitoring on the authentication request, thereby reducing the authentication times on the premise of ensuring the safety and avoiding the waste of computing resources.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

Fig. 1 is a schematic diagram illustrating an exemplary system architecture of a block chain based authentication method and a block chain based authentication apparatus to which an embodiment of the present invention may be applied.

FIG. 2 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

Fig. 3 schematically shows an alternative architecture applied to a blockchain system according to an embodiment of the present application.

Fig. 4 schematically shows a schematic diagram of a Block Structure (Block Structure) according to an embodiment of the present application.

Fig. 5 schematically shows an existing authentication sequence diagram according to an embodiment of the present application.

Fig. 6 schematically shows an existing authentication sequence diagram according to another embodiment of the present application.

Fig. 7 schematically shows a flow chart of a block chain based authentication method according to an embodiment of the application.

FIG. 8 schematically shows a user interface diagram according to an embodiment of the application.

Fig. 9 schematically shows a block structure diagram according to an embodiment of the present application.

Fig. 10 schematically shows a sequence diagram of a block chain based authentication method according to an embodiment of the present application.

Fig. 11 schematically shows a flow chart of a block chain based authentication method according to an embodiment of the present application.

Fig. 12 schematically shows a block diagram of a block chain based authentication apparatus in an embodiment according to the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known technical solutions have not been shown or described in detail to avoid obscuring aspects of the present application.

Furthermore, the drawings are merely schematic illustrations of the present application and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

Fig. 1 is a schematic diagram illustrating a system architecture of an exemplary application environment to which a blockchain-based authentication method and a blockchain-based authentication apparatus according to an embodiment of the present invention may be applied.

As shown in fig. 1, the system architecture 100 may include one or more of terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the terminal devices 101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few. The terminal devices 101, 102, 103 may be various electronic devices having a display screen, including but not limited to desktop computers, portable computers, smart phones, tablet computers, and the like. It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation. For example, the server 105 may be a server cluster formed by a plurality of servers, and the like, and the server may be an independent physical server, a server cluster formed by a plurality of physical servers or a distributed system, and may also be a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, middleware service, a domain name service, a security service, a CDN, and a big data and artificial intelligence platform. The terminal may be, but is not limited to, a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, and the like. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein.

The authentication method based on the blockchain provided by the embodiment of the present application is generally executed by the server 105, and accordingly, the authentication device based on the blockchain is generally disposed in the server 105. However, it is easily understood by those skilled in the art that the block chain based authentication method provided in the embodiment of the present application may also be executed by the terminal device 101, 102, or 103, and accordingly, the block chain based authentication apparatus may also be disposed in the terminal device 101, 102, or 103, which is not particularly limited in this exemplary embodiment. For example, in one exemplary embodiment, the server 105 may, upon receiving the authentication request, validate the authentication request; if the authentication request is verified to be legal, performing consensus on the authentication request and writing the authentication request into a block chain account book; requesting response data from the server according to the writing result, and responding to the authentication request according to the response data; determining the authentication level corresponding to the current user according to the user identification extracted from the authentication request, and calling an intelligent contract so that the intelligent contract carries out time-efficiency monitoring on the authentication request according to the authentication effective duration corresponding to the authentication level; when the expiration of the authentication valid duration is detected, generating a failure voucher for representing the failure of the authentication request, and writing the failure voucher into a block chain account book; wherein, the invalid authentication request can not prove the validity of the current user.

FIG. 2 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

It should be noted that the computer system 200 of the electronic device shown in fig. 2 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 2, the computer system 200 includes a Central Processing Unit (CPU) 201 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM) 202 or a program loaded from a storage section 208 into a Random Access Memory (RAM) 203. In the RAM 203, various programs and data necessary for system operation are also stored. The CPU 201, ROM 202, and RAM 203 are connected to each other via a bus 204. An input/output (I/O) interface 205 is also connected to bus 204.

The following components are connected to the I/O interface 205: an input portion 206 including a keyboard, a mouse, and the like; an output section 207 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 208 including a hard disk and the like; and a communication section 209 including a network interface card such as a LAN card, a modem, or the like. The communication section 209 performs communication processing via a network such as the internet. A drive 210 is also connected to the I/O interface 205 as needed. A removable medium 211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like, is mounted on the drive 210 as necessary, so that a computer program read out therefrom is installed into the storage section 208 as necessary.

In particular, according to embodiments of the present application, the processes described below with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 209 and/or installed from the removable medium 211. The computer program, when executed by a Central Processing Unit (CPU) 201, performs various functions defined in the methods and apparatus of the present application.

The embodiment of the invention relates to cloud computing (cloud computing), wherein a background server can be a cloud server, the cloud computing is a computing mode, and computing tasks are distributed on a resource pool formed by a large number of computers, so that various application systems can acquire computing power, storage space and information service according to needs. The network that provides the resources is referred to as the "cloud". Resources in the "cloud" appear to the user as being infinitely expandable and available at any time, available on demand, expandable at any time, and paid for on-demand. As a basic capability provider of cloud computing, a cloud computing resource pool (called as a cloud Platform in general, an Infrastructure as a Service) Platform is established, and multiple types of virtual resources are deployed in the resource pool for selective use by external clients, the cloud computing resource pool mainly includes a computing device (including an operating system, for a virtualized machine), a storage device, and a network device, and is divided according to logical functions, a PaaS (Platform as a Service) layer may be deployed on an IaaS (Infrastructure as a Service) layer, a SaaS (Software as a Service) layer may be deployed on the PaaS layer, or the SaaS may be directly deployed on the IaaS layer, the PaaS may be a Platform running on Software, such as a web database, a container, and the like, as business Software of various websites, a web portal, and the like, SaaS and PaaS are upper layers relative to IaaS.

The system related to the embodiment of the invention can be a distributed system formed by connecting a client, a server and a plurality of nodes (any type of computing equipment in an access network, such as a server and a user terminal) in a network communication mode.

Taking a distributed system as an example of a blockchain system, referring to fig. 3, fig. 3 is an optional structural schematic diagram of an authentication apparatus 300 based on a blockchain, which is provided in the embodiment of the present invention and applied to the blockchain system, and is formed by a plurality of nodes 301 (any type of computing devices in an access network, such as a server and a user terminal), a backend server 302, a client 303, and a server 304, and when receiving an authentication request sent by the client 303, the authentication request may be legally verified by any node in the plurality of nodes 301; furthermore, if the authentication request is verified to be legal, the authentication request can be identified by a common identification node in the plurality of nodes 301 and written into the block chain account book; further, the backend server 302 may request response data from the server 304 according to the writing result, and respond to the authentication request according to the response data. A point-To-point (P2P, Peer To Peer) network is formed between the nodes, and the P2P Protocol is an application layer Protocol operating on a Transmission Control Protocol (TCP). In a distributed system, any machine, such as a server or a terminal, can join to become a node, and the node comprises a hardware layer, a middle layer, an operating system layer and an application layer.

Referring to the functions of each node in the blockchain system shown in fig. 3, the functions involved include:

1) routing, a basic function that a node has, is used to support communication between nodes.

Besides the routing function, the node may also have the following functions:

2) the application is used for being deployed in a block chain, realizing specific services according to actual service requirements, recording data related to the realization functions to form recording data, carrying a digital signature in the recording data to represent a source of task data, and sending the recording data to other nodes in the block chain system, so that the other nodes add the recording data to a temporary block when the source and integrity of the recording data are verified successfully.

For example, the services implemented by the application include:

2.1) wallet, for providing the function of transaction of electronic money, including initiating transaction (i.e. sending the transaction record of current transaction to other nodes in the blockchain system, after the other nodes are successfully verified, storing the record data of transaction in the temporary blocks of the blockchain as the response of confirming the transaction is valid; of course, the wallet also supports the querying of the electronic money remaining in the electronic money address.

And 2.2) sharing the account book, wherein the shared account book is used for providing functions of operations such as storage, query and modification of account data, record data of the operations on the account data are sent to other nodes in the block chain system, and after the other nodes verify the validity, the record data are stored in a temporary block as a response for acknowledging that the account data are valid, and confirmation can be sent to the node initiating the operations.

2.3) Intelligent contracts, computerized agreements, which can enforce the terms of a contract, implemented by codes deployed on a shared ledger for execution when certain conditions are met, for completing automated transactions according to actual business requirement codes, such as querying the logistics status of goods purchased by a buyer, transferring the buyer's electronic money to the merchant's address after the buyer signs for the goods; of course, smart contracts are not limited to executing contracts for trading, but may also execute contracts that process received information.

3) And the Block chain comprises a series of blocks (blocks) which are mutually connected according to the generated chronological order, new blocks cannot be removed once being added into the Block chain, and recorded data submitted by nodes in the Block chain system are recorded in the blocks.

Referring to fig. 4, fig. 4 is an optional schematic diagram of a Block Structure (Block Structure) provided in the embodiment of the present invention, where each Block includes a hash value of a transaction record stored in the Block (hash value of the Block) and a hash value of a previous Block, and the blocks are connected by the hash values to form a Block chain. The block may include information such as a time stamp at the time of block generation. A block chain (Blockchain), which is essentially a decentralized database, is a string of data blocks associated by using cryptography, and each data block contains related information for verifying the validity (anti-counterfeiting) of the information and generating a next block.

With the continuous development of cloud games, the cloud games become one of the main services provided by the OTT terminal. The OTT end is used for providing various application services for users through the Internet, and can be an Internet television all-in-one machine or (an OTT box + a television). Generally, the client cloud game needs to perform authentication through the background server, and after the authentication is successful, the background server can request cloud game data from the server and feed the cloud game data back to the client. There are two existing solutions to this process, which are represented by the serialization of fig. 5 and 6.

Referring to fig. 5, fig. 5 schematically illustrates a prior art authentication sequence diagram according to an embodiment of the present application. As shown in fig. 5, the existing authentication sequence chart includes: step S510 to step S580. S510: and starting the cloud game. Specifically, the user may start the cloud game through a client (e.g., OTT terminal). S520: and acquiring parameters to be authenticated. Specifically, the client may obtain parameters to be authenticated corresponding to the current device, such as a GUID, an MAC address, a cloud game ID preset in the application program, a cloud game channel ID, encrypted _ key, and the like. S530: an authentication request is sent. Specifically, the client may send an authentication request containing the parameters to be authenticated to the backend server. S540: the authentication request is processed. Specifically, the background server may check the validity of the parameter to be authenticated. S550: and feeding back an authentication result. Specifically, the background server feeds back an authentication result to the background server when the parameter to be authenticated is legal, and the authentication result is used for indicating authentication success or authentication failure. S560: a multimedia file request is sent. Specifically, the background server may send a multimedia file request to the server when the authentication result indicates that the authentication is successful. S570: and feeding back the multimedia file. Specifically, the server side responds to the multimedia file request and feeds back the multimedia file. S580: and sending the multimedia file so that the client renders the content to be displayed according to the multimedia file. Specifically, the server may feed back the multimedia file to the client, so that the client renders the content to be displayed according to the multimedia file and displays the content to be displayed to the user through the user interface. It can be seen that, the above-mentioned scheme mainly relies on the parameter to be authenticated to authenticate, the device information in the parameter to be authenticated can be tampered by means of flashing or modifying the system software, and the cloud game channel ID, encrypted _ key, etc. can also be obtained by decompiling the client software or capturing the network packet message of the authentication request. Therefore, the reliability and the credibility of the authentication result under the mode are lower.

Referring to fig. 6, fig. 6 schematically shows a prior art authentication sequence diagram according to another embodiment of the present application. As shown in fig. 6, the existing authentication sequence diagram includes: step S600 to step S690.

S600: and starting the cloud game. Specifically, the user may start the cloud game through a client (e.g., OTT terminal). S610: and acquiring parameters to be authenticated. Specifically, the client may obtain parameters to be authenticated corresponding to the current device, such as a GUID, an MAC address, a cloud game ID preset in the application program, a cloud game channel ID, encrypted _ key, and the like. S620: a skey is requested. Specifically, the client may send the parameter to be authenticated to the third party backend. S630: and feeding back the skey and the skey validity period. Specifically, the third-party background performs hash calculation according to the parameters to be authenticated to obtain the skey corresponding to the current device, and further allocates an expiration date (namely, the service life of the skey) to the skey, and feeds back the skey and the expiration date of the skey to the client, wherein the skey can be used as the representation of the current device. S640: an authentication request is sent. Specifically, the client may send an authentication request including the parameters to be authenticated, the skey and the skey validity period to the backend server. S650: and (6) delegating authentication. Specifically, the background server may send the authentication request to the third party background to delegate the third party background to perform the authentication operation. S660: and feeding back an authentication result. Specifically, the third-party background may feed back an authentication result to the background server after the authentication is completed, where the authentication result is used to indicate that the authentication is successful or failed. S670: a multimedia file request is sent. Specifically, the background server may send a multimedia file request to the server when the authentication result indicates that the authentication is successful. S680: and feeding back the multimedia file. Specifically, the server side responds to the multimedia file request and feeds back the multimedia file. S690: and sending the multimedia file so that the client renders the content to be displayed according to the multimedia file. Specifically, the server may feed back the multimedia file to the client, so that the client renders the content to be displayed according to the multimedia file and displays the content to be displayed to the user through the user interface. Therefore, the scheme mainly delegates the third party to distribute the identification code and authenticate, the mode has strong dependence on the background server, and if the authentication logic of the background server is wrong or attacked, the authentication result is easy to be wrong and the like.

It can be seen from the existing authentication sequence diagrams shown in fig. 5 and fig. 6 that both authentication manners need to rely on a centralized background server, and when the background server is down, the problem that the authentication cannot be performed in time or cannot be correctly performed is easily caused.

The present example embodiment provides an authentication method based on a block chain. The authentication method based on the blockchain may be applied to the server 105, and may also be applied to one or more of the terminal devices 101, 102, and 103, which is not particularly limited in this exemplary embodiment. Referring to fig. 7, the authentication method based on the block chain may include the following steps S710 to S750.

Step S710: when the authentication request is received, the validity of the authentication request is verified.

Step S720: and if the authentication request is verified to be legal, performing consensus on the authentication request and writing the authentication request into the block chain account book.

Step S730: and requesting response data from the server according to the writing result, and responding to the authentication request according to the response data.

Step S740: and determining the authentication level corresponding to the current user according to the user identification extracted from the authentication request, and calling an intelligent contract so that the intelligent contract carries out time-efficiency monitoring on the authentication request according to the authentication effective duration corresponding to the authentication level.

Step S750: when the expiration of the authentication valid duration is detected, generating a failure voucher for representing the failure of the authentication request, and writing the failure voucher into a block chain account book; wherein, the invalid authentication request can not prove the validity of the current user.

The steps S710 to S750 may be executed by a background server, and when the application is applied to the field of cloud games, the background server may be a cloud game background server; the cloud game is a game mode based on cloud computing, all games run at a server side in a running mode of the cloud game, game pictures rendered by the server side are compressed and then can be transmitted to a client side through a network, and further, game equipment running the client side can decompress a video function, so that the game pictures are obtained. In addition, a block chain based on a alliance chain is maintained in the cloud game background server; wherein the federation chains are established on a certain number of preselected authentication nodes. The consensus algorithm of the blockchain is executed by the preselected nodes (i.e., the consensus nodes), which can reduce the occupation of network resources. The preselection node is cloud game background group node, and cloud game background group node can be a plurality of node servers.

By implementing the method shown in fig. 7, after receiving the authentication request, the authentication request can be verified, identified and written by using the uniqueness, non-tamper property and reliability of the decentralized block link network, thereby ensuring the legality and privacy of the authentication request and preventing the malicious authentication request from attacking the background server. In addition, the advantage of block chain distributed storage can be utilized, the problem that the authentication cannot be performed in time after the shutdown of the background server in the prior art is solved, and the stability of the authentication process is improved. In addition, the validity monitoring can be carried out on the authentication request, so that the current user has validity in the personalized valid authentication duration, the authentication times are reduced on the premise of ensuring the safety, and the waste of computing resources is avoided.

The above steps of the present exemplary embodiment will be described in more detail below.

In step S710, when the authentication request is received, the authentication request is legally verified.

Specifically, the request content of the authentication request may include: parameters to be authenticated and data requested to be obtained (e.g., video data, real-time game frames, etc.). The parameters to be authenticated may include: cloud game ID, cloud game channel ID, Global Unique Identifier (GUID), and Message Authentication Code (MAC); the MAC is a Hash function containing a key, is a value obtained based on the key and a message digest, can be used for data source authentication and integrity verification, and has the security depending on the Hash function; a GUID is an algorithmically generated numeric identifier of 128 bits in binary length that can be used in a network or system having multiple nodes, multiple computers, and generally no computer or cluster of computers generates two identical GUIDs.

As an optional embodiment, before performing validity verification on the authentication request, the method further includes: and receiving the encrypted authentication request sent by the client and decrypting the authentication request.

Specifically, decrypting the authentication request includes: and decrypting the authentication request through the client public key. Further, the validity verification of the authentication request includes: and verifying whether the GUID and the MAC in the authentication request are legal or not.

Therefore, the implementation of the optional embodiment can improve the data security in the request transmission process by encrypting and decrypting the authentication request.

As an alternative embodiment, before receiving the encrypted authentication request sent by the client, the method further includes: the client encrypts the parameters to be authenticated and generates an encrypted authentication request according to the encrypted parameters to be authenticated and sends the encrypted authentication request to the background server.

Specifically, the client may be an OTT terminal. The client side encrypts the parameters to be authenticated, and the method comprises the following steps: and the client encrypts the parameters to be authenticated through the client private key.

In addition, before the client encrypts the parameter to be authenticated, the method may further include: and accessing the cloud game when the client detects the access operation. The access operation may be a login operation, and the user may log in a client (e.g., an OTT terminal) through an account password, and then obtain cloud game resources through the client.

Referring to FIG. 8, FIG. 8 schematically illustrates a user interface diagram according to an embodiment of the present application. The user interface shown in fig. 8 shows a plurality of cloud games running in a game hall of the OTT terminal, the cloud games shown in the user interface belong to games under a "recommendation" function, and a user can trigger the OTT terminal to show the games under corresponding functions by selecting a "remote controller game" function and a "handle game" function. Specifically, the user may select a plurality of games in the user interface shown in fig. 8, and when the user triggers starting of any game in the plurality of games, the OTT terminal (i.e., the client) may determine the parameter to be authenticated corresponding to the trigger operation, encrypt the parameter to be authenticated, and generate an encrypted authentication request according to the encrypted parameter to be authenticated, and send the encrypted authentication request to the background server.

Therefore, by implementing the optional embodiment, the parameter to be authenticated can be encrypted through the client, the security of the parameter to be authenticated is improved, and the probability of stealing the parameter to be authenticated in the authentication request is reduced.

As an optional embodiment, the client encrypts the parameter to be authenticated, including: the client encrypts the parameters to be authenticated through a symmetric encryption algorithm or an asymmetric encryption algorithm.

The symmetric encryption algorithm is an encryption algorithm using the same key for encryption and decryption, and can be a DES algorithm, a 3DES algorithm, a TDEA algorithm, a Blowfish algorithm, an RC5 algorithm, an IDEA algorithm and the like; the asymmetric encryption algorithm refers to an encryption algorithm using different keys for encryption and decryption, and the asymmetric encryption algorithm may be an RSA algorithm, an Elgamal algorithm, a knapsack algorithm, a Rabin algorithm, a D-H algorithm, or an elliptic curve encryption algorithm (ECC), and the embodiment of the present application is not limited.

Specifically, the method for encrypting the parameters to be authenticated by the client through the symmetric encryption algorithm may be as follows: the client encrypts the parameters to be authenticated through the preset secret key, so that the background server can decrypt the parameters through the preset secret key when receiving the authentication request. The method for encrypting the parameters to be authenticated by the client through the asymmetric encryption algorithm can be as follows: the client encrypts the parameters to be authenticated through the user private key so that the background server can decrypt the parameters through the user public key when receiving the authentication request.

Therefore, by implementing the optional embodiment, the security of the authentication parameters in the transmission process can be improved by encrypting the authentication parameters.

In step S720, if it is verified that the authentication request is legal, the authentication request is identified and written into the block chain ledger.

Optionally, the consensus on the authentication request includes: the authentication request is identified through a Proof of Work (PoW) mechanism; the method specifically comprises the following steps: after the authentication request is verified to have validity, the authentication request is broadcasted to the block chain network and is written into a transaction pool as transaction information; furthermore, the consensus node in the block chain network can pack the transaction information in the transaction pool under the condition that a preset packing condition is met, calculate the random number (Nonce) of the packed block, and write the block into the block chain if the target node in the consensus node calculates a random number and the random number meets the difficulty target of generating the block. The preset packing condition may be that the number of the transaction information in the transaction pool meets a preset number, or the preset packing condition may be that the unit time (for example, 20 ms) is met.

Further, calculating the random number of the packed block comprises: each consensus node calculates n (random number) meeting the expression H (n H) less than or equal to t, and determines the consensus node which calculates n firstly as a target node; h (n | | H) is a hash function of the SHA256 algorithm, t is a difficulty target, and H is data of a block header. The SHA256 algorithm is used to generate a 256-bit hash value (i.e., message digest) for a message of arbitrary length, which is equal to an array of 32 bytes in length, which can be represented by 64 hexadecimal characters.

As an alternative embodiment, the consensus on the authentication request includes: and inquiring whether a branch node corresponding to the authentication request exists in the Mercker tree of the block chain account book, and if not, identifying the authentication request.

Specifically, the Mercker tree is a binary tree, which is composed of a set of leaf nodes (e.g., transaction information 1, transaction information 2, … …, transaction information n, n is a positive integer), a set of intermediate nodes (e.g., Hash1, Hash2, … …, Hash n, Hash12, Hash23, Hash34, Hash1234, etc.), and a root node (Merkel root), and each block contains a Mercker tree. In addition, the time complexity of inquiring whether a branch node corresponding to the authentication request exists in the merkel tree of the block chain account book is O (log)₂n), where O is the complexity calculation function and n is the data volume.

Based on this, inquiring whether a branch node corresponding to the authentication request exists in the merkel tree of the block chain account book includes: acquiring branch link information in the authentication request, determining a block corresponding to the authentication request according to a root node in the branch link information, positioning the block, and calculating a leaf node according to an intermediate node in the branch link information; if the leaf node is consistent with one leaf node in the Mercker tree, judging that a branch node corresponding to the authentication request exists in the Mercker tree; if the leaf node is not consistent with one leaf node in the Mercker tree, judging that no branch node corresponding to the authentication request exists in the Mercker tree.

Based on this, if there is a branch node corresponding to the authentication request in the merkel tree, the method may further include: and judging that the authentication request passes the authentication, and sending a multimedia file request to the server so that the server feeds back the corresponding multimedia file as response data according to the request content corresponding to the authentication request.

It can be seen that, by implementing the optional embodiment, the uplink authentication request can be made for the client that requested for the first data, and when the client requests for the data again, whether uplink information corresponding to the client exists is determined by the node check method, and if the uplink information exists, the request can be directly determined to be legal, so that not only is the security of the authentication process and the non-tamper-resistance of the authentication result improved, but also the response efficiency to the re-request can be improved.

As an optional embodiment, after writing the authentication request into the blockchain ledger, the method further includes: determining a branch node corresponding to the authentication request from the Mercker tree; and feeding back the branch nodes to the client sending the authentication request.

Specifically, the number of the branch nodes may be one or more, and a plurality of branch nodes may constitute branch chain information, such as mercker root-Hash 12-Hash2-Tx2, and the transaction information containing the authentication request corresponds to the node Tx 2.

In addition, after feeding back the branch node to the client sending the authentication request, the method may further include: and the client updates the parameters to be authenticated according to the branch nodes, wherein the updated parameters to be authenticated comprise information for describing the branch nodes.

It can be seen that, by implementing this alternative embodiment, the client can directly send the request containing the branch node when requesting the next multimedia data through the feedback to the branch node, and the background server can request the required multimedia data for the client through the successful verification of the branch node, wherein the non-tamper property and uniqueness of the block link network are utilized, and after the successful verification that the branch node really exists in the merkel tree, the validity of the client can be proved. Compared with the prior art that authentication is carried out through a centralized background server, the authentication mode has higher reliability, and the problem that the centralized background server cannot execute normal authentication operation after being attacked is avoided to a certain extent.

As an optional embodiment, after feeding back the branch node to the client sending the authentication request, the method further includes: the client generates a new authentication request according to the authentication abstract in the branch node and sends the new authentication request to the background server.

In particular, the new authentication request may include an authentication digest in the finger node.

Therefore, the implementation of the alternative embodiment can improve the response efficiency of the subsequent request by the uplink of the first request.

As an alternative embodiment, the consensus on the authentication request and the writing of the authentication request into the block chain ledger includes: the authentication request is identified through an identification node and written into a block chain account book; the ratio between the number of the common nodes and the total number of the nodes in the blockchain is within a predetermined range (e.g., 0-20%).

For example, when the total number of nodes in the blockchain is 5000, the number of common nodes may be 1010, 1010/5000= 20%. In addition, the method for performing consensus on the authentication request through the consensus node and writing the authentication request into the block chain account book comprises the following steps: the consensus node performs consensus on the authentication request according to a Byzantine Fault Tolerance (PBFT) and writes the authentication request into a block chain account book.

Therefore, the implementation of the optional embodiment can change the verification of cloud game authentication from a centralized background system to a decentralized block chain system, thereby improving the reliability, uniqueness and non-tamper property of the authentication result.

As an alternative embodiment, performing consensus on the authentication request by the consensus node and writing the authentication request into the blockchain ledger includes: broadcasting the authentication request so that each consensus node calculates an authentication digest of the block to which the authentication request belongs: determining a consensus result according to the consistency of the authentication abstract calculated by each consensus node; and if the consensus result accords with the preset result, writing the block into a block chain account book.

Specifically, the blocks in the block chain account book are in a chain structure, and each block comprises a block head and a block body. The block body is used for storing a plurality of downloading records which occur after the previous block. Fields in the block header include a version, a previous block hash (PreBlockHash), merkel Root (Merkle Root), a timestamp, preset conditions, a target random number (Nonce), and an authentication digest, and the block header can be represented as the following table.

The first column is fields contained in the block header, the second column is description explanation of the fields in the first column, and the third column is size of bytes occupied by each field in the first column.

Accordingly, the data structure corresponding to the block header is as follows:

struct MyBlockHeader

{

string Block version// version

string previous Block Hash// previous Block Hash

string MerkleRootNode// Mercker root node

string timestamp

int difficult;/preset conditions

int nonce// random number

string data, verification data containing authentication abstract

}。

Referring to fig. 9, fig. 9 schematically illustrates a block structure according to an embodiment of the present application. As shown in fig. 9, which schematically shows a block 910, a block 920 and a block 930 in a block chain, a plurality of blocks (not shown) may be included before the block 910, and a plurality of blocks (not shown) may be included after the block 930. Specifically, blocks 910, 920, and 930 may each include a block header and a block body, with the block header including a previous block hash (PreviousBlockHash), a random number (Nonce), and a merkel root (MerkleRoot). The block of block 920 is shown in detail, and the blocks of blocks 910 and 930 are omitted. Each merkel node may be included in the block body of block 920: tx1, Tx2, Tx3, Tx4, Hash value Hash1 corresponding to Tx1, Hash value Hash2 corresponding to Tx2, Hash value Hash3 corresponding to Tx3, Hash value Hash4 corresponding to Tx4, Hash value 12 corresponding to Hash value Hash1 and Hash value Hash2, Hash value Hash3 and Hash value Hash34 corresponding to Hash value Hash 4. From the hash value 12 and the hash value 34, a Merkle Root (Merkle Root) in the block header can be calculated.

In addition, before broadcasting the authentication request so that each consensus node calculates the authentication digest of the block to which the authentication request belongs, the method may further include: and selecting a main node from all the consensus nodes, wherein the main node does not participate in the calculation of the authentication abstract and is used for recording transaction information and writing in a block. Wherein, select the host node from all consensus nodes, including: and selecting a main node from all the consensus nodes according to the random countdown duration allocated to each consensus node, wherein the random countdown duration corresponding to the selected main node is firstly finished. In addition, the method may further include: if the master node crashes, a new master node can be selected from all the remaining consensus nodes through the random countdown duration allocated to each consensus node.

Based on this, the broadcast authentication request includes: the main node broadcasts an authentication request; or the main node determines other requests in the same receiving period with the authentication request, sorts the requests according to the receiving time and broadcasts the sorting result. Furthermore, if the master node sorts and broadcasts the sorting result according to the receiving time, each consensus node calculates the authentication abstract of the block to which the authentication request belongs, comprising: and each consensus node calculates an authentication abstract corresponding to the sequencing result.

Based on this, determining a consensus result according to the consistency of the authentication abstract calculated by each consensus node, and writing the block into a block chain account book, the method comprises the following steps: the main node receives the authentication abstracts calculated by the consensus nodes and determines whether the authentication abstracts calculated by the consensus nodes meet the requirement (the total number of the consensus nodes is more than 3n + 1); if the requirement is met (the total number of the consensus nodes is greater than 3n + 1), judging that consistency exists between the authentication abstracts calculated by each consensus node, and determining a consensus result for representing successful consensus; then, the main node writes the block into a block chain account book; if the authentication result does not meet the requirement (the total number of the consensus nodes is greater than 3n + 1), judging that consistency does not exist between the authentication abstracts calculated by each consensus node, and determining a consensus result for representing consensus failure; where n is the maximum number of nodes that may crash/fail.

Therefore, by implementing the optional embodiment, the legality and correctness of the authentication request can be ensured by chaining the authentication request, the normal response of the server to the normal user request is ensured, and the server is prevented from being attacked by malicious access of forging the normal user request.

In step S730, response data is requested from the server according to the writing result, and the authentication request is responded according to the response data.

In particular, the write result may be used to indicate a write blockchain success or to indicate a write blockchain failure. In addition, the response data can be multimedia data, and when the application is applied to the field of cloud games, a real-time/non-real-time game picture can be requested from the server.

As an alternative embodiment, requesting response data from the server according to the write result includes: and judging that the authentication request passes the authentication according to the writing result, and sending a multimedia file request to the server so that the server feeds back the corresponding multimedia file as response data according to the request content corresponding to the authentication request.

Specifically, the multimedia file request may include authenticated device information (e.g., device ID), game information (e.g., cloud game ID), and the like.

It can be seen that implementing this alternative embodiment enables the request to be subjected to authentication consensus accounting using distributed storage, thereby ensuring correctness and non-tampering of parameters in the stored authentication request.

As an alternative embodiment, responding to the authentication request according to the response data includes: and feeding back the multimedia file to the client sending the authentication request so that the client renders the content to be displayed according to the multimedia file.

Specifically, after the client renders the content to be displayed according to the multimedia file, the method may further include: and displaying the rendered content to be displayed on a user interface, wherein the content to be displayed can be a game picture.

It can be seen that, by implementing this alternative embodiment, the uniqueness, non-tamper-ability, and reliability of the decentralized block link network can be utilized to improve the security and stability of the authentication process.

In step S740, the authentication level corresponding to the current user is determined according to the user identifier extracted from the authentication request, and the intelligent contract is invoked, so that the intelligent contract performs the aging monitoring on the authentication request according to the authentication valid duration corresponding to the authentication level.

Specifically, the user identifier may be represented as a character string, the authentication validity duration (e.g., 2 hours) is used to represent the duration of validity of the current user, and the authentication level is at least two.

In addition, it should be noted that the intelligent contract is a contract term which is compiled by an algorithm and a program, is deployed on a blockchain, and is a digital agreement which can be automatically executed according to a rule. Decentralized blocking of blockchains allows intelligent complexes to run simultaneously on all nodes of the entire network without the involvement of a central administrator. In the application, the intelligent contract is not directly operated on the blockchain node, so that the security of the blockchain node is prevented from being threatened when the contract contains malicious codes or vulnerabilities. The intelligent contract runs in a sandbox environment based on an open source block chain distributed account book (HyperLegger Fabric), wherein the deployed intelligent contract can be packaged into a Docker mirror image, and each node can start a new Docker container based on the mirror image and execute algorithm rules in the contract.

As an optional embodiment, before determining the authentication level corresponding to the current user according to the user identifier extracted from the authentication request, the method further includes: acquiring a recharging record corresponding to the current user, and determining an authentication level corresponding to the current user according to the recharging record; the authentication level corresponding to the current user is changed along with the change of the recharging record corresponding to the current user, and the authentication level corresponding to the current user is positively correlated with the authentication effective duration corresponding to the current user.

Specifically, obtaining a recharge record corresponding to a current user includes: and acquiring at least one recharging record corresponding to the current user in unit time, and determining the authentication level corresponding to the current user according to the recharging record. For example, the unit time is 1 week, the authentication level of the user with the total recharge amount of >100 is a, and the authentication valid duration corresponding to the a is 1 hour; the authentication level of the user with the total recharging amount of 100-500 is B, and the effective authentication time corresponding to B is 5 hours; the authentication level of the user with the total recharging amount of 500-1000 is C, and the authentication effective time corresponding to C is 100 hours; the authentication level of the user with the total recharging amount of <1000 is D, and the authentication effective duration corresponding to D is 280 hours.

Therefore, the optional embodiment can be implemented to determine the authentication level suitable for the user in an individualized way based on the recharging record of the user, so that the authentication efficiency is improved on the premise of ensuring the authentication accuracy, and the individualized degree of the authentication is improved.

As an alternative embodiment, determining the authentication level corresponding to the current user according to the user identifier extracted from the authentication request includes: extracting a user identifier corresponding to the current user from the authentication request; determining a target block in a block chain account book for recording each user grade; and reading the authentication level corresponding to the user identification from the Mercker tree of the target block.

Specifically, the target block is used for recording the latest user level, and the updating time of the user level is later than the recharging time of the user. Based on this, before extracting the user identifier corresponding to the current user from the authentication request, the method further includes: and updating the user grade corresponding to the user with the recharging behavior by taking the preset time (such as 1 hour) as a time interval.

Therefore, by implementing the optional embodiment, the latest authentication level can be determined according to the backtracking of the block, so that the personalized effective authentication duration for the current user can be determined, the authentication efficiency can be improved, and the allocation of computer resources can be optimized.

As an optional embodiment, invoking the intelligent contract to enable the intelligent contract to perform aging monitoring on the authentication request according to the authentication validity duration corresponding to the authentication level, and before detecting that the authentication validity duration expires, further includes: when a secondary authentication request corresponding to the current user is received, detecting whether a block corresponding to the secondary authentication request exists in a block chain account book or not; and if so, requesting secondary response data from the server and feeding back the secondary response data to the client side requesting the secondary authentication.

Specifically, the intelligent contract can monitor the time effectiveness and can also perform expense settlement, and the secondary authentication request is a request within the valid authentication duration, so that the validity of the secondary authentication request can be proved only by verifying the existence of the detection result of the first authentication request in the verification block without executing the validity verification step.

Therefore, the implementation of the optional embodiment can avoid repeated authentication within the personalized authentication effective duration corresponding to the current user, so as to improve the efficiency of feeding back data to the client when the client requests the data.

In step S750, when it is detected that the authentication valid duration expires, generating a failure credential for characterizing failure of the authentication request, and writing the failure credential into a block chain book; wherein, the invalid authentication request can not prove the validity of the current user.

In particular, the revocation credential may be constructed by a data table containing a plurality of fields.

As an optional embodiment, invoking the intelligent contract to enable the intelligent contract to perform aging monitoring on the authentication request according to the authentication validity duration corresponding to the authentication level includes: starting to perform time-efficiency monitoring on the authentication request after responding to the authentication request; if the authentication effective duration corresponding to the authentication level is not expired and the client for receiving the response data stops receiving the data, determining the data transmission duration; and calling an intelligent contract to calculate a target fee for the data transmission duration and deducting the target fee from the account of the current user.

Specifically, determining the data transmission duration includes: determining continuous data transmission duration by taking the received response authentication request as starting time and the moment when the client stops receiving data as ending time; wherein, the data transmission duration may be a game duration.

Therefore, by implementing the optional embodiment, the intelligent contract can be called to realize monitoring on the time efficiency and real-time calculation on the cost, so that the user can feel service experience in different recharging environments.

Referring to fig. 10, fig. 10 schematically shows a sequence diagram of a block chain based authentication method according to an embodiment of the present application. As shown in fig. 10, the sequence diagram may include: step S1010 to step S1080.

S1010: and starting the cloud game. Specifically, the user may start the cloud game through a client (e.g., OTT terminal).

S1020: an authentication request is sent. Specifically, the client may obtain parameters to be authenticated corresponding to the current device, such as a GUID, an MAC address, a cloud game ID preset in an application program, a cloud game channel ID, encrypted _ key, and the like, and further send an authentication request including the authentication parameters to the backend server.

S1030: the validity of the authentication request is checked. Specifically, a block chain maintained inside the background server checks the validity of the parameter to be authenticated.

S1040: and carrying out consensus accounting on the legal authentication request. Specifically, the consensus node of the blockchain maintained inside the background server may perform consensus accounting on a legal authentication request, and specifically includes: broadcasting the authentication request so that each consensus node calculates the authentication abstract of the block to which the authentication request belongs, determining a consensus result according to the consistency of the authentication abstract calculated by each consensus node, and writing the block into a block chain account book if the consensus result accords with a preset result.

S1050: and feeding back the branch node of the Mercker tree corresponding to the authentication request. Specifically, the background server may feed back the branch node of the mercker tree corresponding to the authentication request to the client, so that the client may directly send a request including the branch node when requesting the multimedia data next time, thereby avoiding the consensus accounting process.

S1060: a multimedia file request is sent. Specifically, the background server may send a multimedia file request to the server when the authentication result indicates that the authentication is successful.

S1070: and feeding back the multimedia file. Specifically, the server side responds to the multimedia file request and feeds back the multimedia file.

S1080: and sending the multimedia file so that the client renders the content to be displayed according to the multimedia file. Specifically, the server may feed back the multimedia file to the client, so that the client renders the content to be displayed according to the multimedia file and displays the content to be displayed to the user through the user interface.

Referring to fig. 11, fig. 11 schematically shows a flow chart of a block chain based authentication method according to an embodiment of the present application. As shown in fig. 11, the authentication method based on the block chain may include: step S1100 to step S1170.

Step S1100: the client encrypts the parameters to be authenticated and generates an encrypted authentication request according to the encrypted parameters to be authenticated and sends the encrypted authentication request to the background server.

Step S1110: the background server receives the encrypted authentication request sent by the client and decrypts the authentication request.

Step S1120: and when receiving the authentication request, the background server carries out validity verification on the authentication request. If the authentication request is verified to be valid, step S1130 is executed. If the authentication request is verified to have no validity, the process is ended.

Step S1130: and the background server inquires whether a branch node corresponding to the authentication request exists in the Mercker tree of the block chain account book or not. If so, step S1170 is performed. If not, step S1140 is performed.

Step S1140: the background server performs consensus on the authentication request through the consensus node and writes the authentication request into a block chain account book; the ratio between the number of the common nodes and the total number of the nodes in the block chain is within a preset range.

Step S1150: the background server determines the branch node corresponding to the authentication request from the Mercker tree and feeds back the branch node to the client sending the authentication request.

Step S1160: and the background server judges that the authentication request passes the authentication according to the writing result and sends a multimedia file request to the server so that the server feeds back the corresponding multimedia file as response data according to the request content corresponding to the authentication request.

Step S1170: and the background server feeds back the multimedia file to the client side sending the authentication request so that the client side renders the content to be displayed according to the multimedia file.

It should be noted that steps S1100 to S1170 correspond to the steps and the embodiment shown in fig. 7, and for the specific implementation of steps S1100 to S1170, please refer to the steps and the embodiment shown in fig. 7, which will not be described again.

It can be seen that, by implementing the method shown in fig. 11, after receiving the authentication request, the authentication request can be verified, identified and written by using the uniqueness, non-tamper resistance and reliability of the decentralized block link network, thereby ensuring the validity and privacy of the authentication request and preventing the malicious authentication request from attacking the background server. In addition, the advantage of block chain distributed storage can be utilized, the problem that the authentication cannot be performed in time after the shutdown of the background server in the prior art is solved, and the stability of the authentication process is improved. In addition, the validity monitoring can be carried out on the authentication request, so that the current user has validity in the personalized valid authentication duration, the authentication times are reduced on the premise of ensuring the safety, and the waste of computing resources is avoided.

Further, in this example embodiment, an authentication apparatus based on a block chain is also provided. Referring to fig. 12, the block chain based authentication apparatus 1200 may include:

a request verification unit 1201, configured to perform validity verification on the authentication request when the authentication request is received;

a request consensus unit 1202, configured to perform consensus on the authentication request and write the authentication request into the block chain ledger when it is verified that the authentication request is legal;

a request response unit 1203, configured to request response data from the server according to the write result, and respond to the authentication request according to the response data;

the aging monitoring unit 1204 is configured to determine an authentication level corresponding to the current user according to the user identifier extracted from the authentication request, and invoke an intelligent contract, so that the intelligent contract performs aging monitoring on the authentication request according to an authentication valid duration corresponding to the authentication level;

a failure information uplink unit 1205, configured to generate a failure credential for representing that the authentication request is failed when it is detected that the authentication valid duration expires, and write the failure credential into the block chain ledger; wherein, the invalid authentication request can not prove the validity of the current user.

It can be seen that, by implementing the apparatus shown in fig. 12, after receiving the authentication request, the apparatus can perform verification, consensus identification, and write on the authentication request by using the uniqueness, non-tamper-resistance, and reliability of the decentralized block link network, thereby ensuring the validity and privacy of the authentication request and preventing the malicious authentication request from attacking the backend server. In addition, the advantage of block chain distributed storage can be utilized, the problem that the authentication cannot be performed in time after the shutdown of the background server in the prior art is solved, and the stability of the authentication process is improved. In addition, the validity monitoring can be carried out on the authentication request, so that the current user has validity in the personalized valid authentication duration, the authentication times are reduced on the premise of ensuring the safety, and the waste of computing resources is avoided.

In an exemplary embodiment of the present disclosure, the determining, by the aging monitoring unit 1204, an authentication level corresponding to the current user according to the user identifier extracted from the authentication request includes:

extracting a user identifier corresponding to the current user from the authentication request;

determining a target block in a block chain account book for recording each user grade;

and reading the authentication level corresponding to the user identification from the Mercker tree of the target block.

Therefore, by implementing the optional embodiment, the latest authentication level can be determined according to the backtracking of the block, so that the personalized effective authentication duration for the current user can be determined, the authentication efficiency can be improved, and the allocation of computer resources can be optimized.

In an exemplary embodiment of the present disclosure, the aging monitor unit 1204 invokes the intelligent contract, so that after the intelligent contract performs aging monitoring on the authentication request according to the authentication validity duration corresponding to the authentication level, and before the chain failure information unit 1205 detects that the authentication validity duration expires, the method further includes:

a detecting unit (not shown) configured to detect whether a block corresponding to the secondary authentication request exists in the block chain account when the secondary authentication request corresponding to the current user is received;

the request responding unit 1203 is further configured to, after the detecting unit detects that a block corresponding to the secondary authentication request exists in the block chain ledger, request secondary response data from the server and feed back the secondary response data to the client of the secondary authentication request.

Therefore, the implementation of the optional embodiment can avoid repeated authentication within the personalized authentication effective duration corresponding to the current user, so as to improve the efficiency of feeding back data to the client when the client requests the data.

In an exemplary embodiment of the present disclosure, the aging monitoring unit 1204 invokes the intelligent contract to enable the intelligent contract to perform aging monitoring on the authentication request according to the authentication valid duration corresponding to the authentication level, including:

starting to perform time-efficiency monitoring on the authentication request after responding to the authentication request;

if the authentication effective duration corresponding to the authentication level is not expired and the client for receiving the response data stops receiving the data, determining the data transmission duration;

and calling an intelligent contract to calculate a target fee for the data transmission duration and deducting the target fee from the account of the current user.

Therefore, by implementing the optional embodiment, the intelligent contract can be called to realize monitoring on the time efficiency and real-time calculation on the cost, so that the user can feel service experience in different recharging environments.

In an exemplary embodiment of the present disclosure, further comprising:

an authentication level determining unit (not shown) configured to obtain a recharge record corresponding to the current user before the aging monitoring unit 1204 determines the authentication level corresponding to the current user according to the user identifier extracted from the authentication request, and determine the authentication level corresponding to the current user according to the recharge record;

the authentication level corresponding to the current user is changed along with the change of the recharging record corresponding to the current user, and the authentication level corresponding to the current user is positively correlated with the authentication effective duration corresponding to the current user.

Therefore, the optional embodiment can be implemented to determine the authentication level suitable for the user in an individualized way based on the recharging record of the user, so that the authentication efficiency is improved on the premise of ensuring the authentication accuracy, and the individualized degree of the authentication is improved.

In an exemplary embodiment of the present disclosure, further comprising:

a request receiving unit (not shown) configured to receive the encrypted authentication request sent by the client and decrypt the authentication request before the request verifying unit 1201 verifies the validity of the authentication request.

Therefore, the implementation of the optional embodiment can improve the data security in the request transmission process by encrypting and decrypting the authentication request.

In an exemplary embodiment of the present disclosure, before the request receiving unit receives the encrypted authentication request sent by the client, the client encrypts the parameter to be authenticated and generates an encrypted authentication request according to the encrypted parameter to be authenticated, and sends the encrypted authentication request to the background server.

Therefore, by implementing the optional embodiment, the parameter to be authenticated can be encrypted through the client, the security of the parameter to be authenticated is improved, and the probability of stealing the parameter to be authenticated in the authentication request is reduced.

In an exemplary embodiment of the present disclosure, the encrypting, by a client, a parameter to be authenticated includes:

the client encrypts the parameters to be authenticated through a symmetric encryption algorithm or an asymmetric encryption algorithm.

Therefore, by implementing the optional embodiment, the security of the authentication parameters in the transmission process can be improved by encrypting the authentication parameters.

In an exemplary embodiment of the present disclosure, the request consensus unit 1202 performs consensus on the authentication request, including:

and inquiring whether a branch node corresponding to the authentication request exists in the Mercker tree of the block chain account book, and if not, identifying the authentication request.

It can be seen that, by implementing the optional embodiment, the uplink authentication request can be made for the client that requested for the first data, and when the client requests for the data again, whether uplink information corresponding to the client exists is determined by the node check method, and if the uplink information exists, the request can be directly determined to be legal, so that not only is the security of the authentication process and the non-tamper-resistance of the authentication result improved, but also the response efficiency to the re-request can be improved.

In an exemplary embodiment of the present disclosure, further comprising:

a node determination unit (not shown) configured to determine a branch node corresponding to the authentication request from the merkel tree after the request consensus unit 1202 writes the authentication request into the block chain ledger;

a node feedback unit (not shown) for feeding back the branch node to the client sending the authentication request.

It can be seen that, by implementing this alternative embodiment, the client can directly send the request containing the branch node when requesting the next multimedia data through the feedback to the branch node, and the background server can request the required multimedia data for the client through the successful verification of the branch node, wherein the non-tamper property and uniqueness of the block link network are utilized, and after the successful verification that the branch node really exists in the merkel tree, the validity of the client can be proved. Compared with the prior art that authentication is carried out through a centralized background server, the authentication mode has higher reliability, and the problem that the centralized background server cannot execute normal authentication operation after being attacked is avoided to a certain extent.

In an exemplary embodiment of the present disclosure, after the node feedback unit feeds back the branch node to the client sending the authentication request, the client generates a new authentication request according to the authentication digest in the branch node, and sends the new authentication request to the background server.

Therefore, the implementation of the alternative embodiment can improve the response efficiency of the subsequent request by the uplink of the first request.

In an exemplary embodiment of the present disclosure, the requesting response unit 1203 requests response data from the server according to the writing result, including:

and judging that the authentication request passes the authentication according to the writing result, and sending a multimedia file request to the server so that the server feeds back the corresponding multimedia file as response data according to the request content corresponding to the authentication request.

It can be seen that implementing this alternative embodiment enables the request to be subjected to authentication consensus accounting using distributed storage, thereby ensuring correctness and non-tampering of parameters in the stored authentication request.

In an exemplary embodiment of the present disclosure, the request responding unit 1203 responds to the authentication request according to the response data, including:

and feeding back the multimedia file to the client sending the authentication request so that the client renders the content to be displayed according to the multimedia file.

It can be seen that, by implementing this alternative embodiment, the uniqueness, non-tamper-ability, and reliability of the decentralized block link network can be utilized to improve the security and stability of the authentication process.

In an exemplary embodiment of the present disclosure, the request consensus unit 1202 performs consensus on the authentication request and writes the authentication request into the block chain ledger, including:

the authentication request is identified through an identification node and written into a block chain account book; the ratio between the number of the common nodes and the total number of the nodes in the block chain is within a preset range.

Therefore, the implementation of the optional embodiment can change the verification of cloud game authentication from a centralized background system to a decentralized block chain system, thereby improving the reliability, uniqueness and non-tamper property of the authentication result.

In an exemplary embodiment of the present disclosure, the request consensus unit 1202 performs consensus on the authentication request through the consensus node and writes the authentication request into the block chain ledger, including:

broadcasting the authentication request so that each consensus node calculates an authentication digest of the block to which the authentication request belongs:

determining a consensus result according to the consistency of the authentication abstract calculated by each consensus node;

and if the consensus result accords with the preset result, writing the block into a block chain account book.

Wherein, the block at least comprises: version, previous chunk hash, mercker root, timestamp, preset conditions, target random number, and authentication digest.

Therefore, by implementing the optional embodiment, the legality and correctness of the authentication request can be ensured by chaining the authentication request, the normal response of the server to the normal user request is ensured, and the server is prevented from being attacked by malicious access of forging the normal user request.

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

For details that are not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the authentication method based on a block chain described above for the details that are not disclosed in the embodiments of the apparatus of the present application.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by an electronic device, cause the electronic device to implement the method described in the above embodiments.

It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims (15)

1. An authentication method based on a block chain is characterized by comprising the following steps:

when receiving an authentication request, carrying out validity verification on the authentication request;

if the authentication request is verified to have validity, performing consensus on the authentication request and writing the authentication request into a block chain account book;

requesting response data from a server according to the writing result, and responding to the authentication request according to the response data;

determining the authentication level corresponding to the current user according to the user identification extracted from the authentication request;

calling an intelligent contract to enable the intelligent contract to carry out time effectiveness monitoring on the authentication request according to the authentication effective duration corresponding to the authentication level;

when the authentication valid duration is detected to expire, generating a failure certificate for representing the failure of the authentication request, and writing the failure certificate into the block chain account book; and the invalid authentication request cannot prove the validity of the current user.

2. The method of claim 1, wherein determining the authentication level corresponding to the current user according to the user identifier extracted from the authentication request comprises:

extracting a user identifier corresponding to the current user from the authentication request;

determining a target block used for recording each user grade in the block chain account book;

and reading the authentication level corresponding to the user identification from the Mercker tree of the target block.

3. The method of claim 1, wherein invoking an intelligent contract to enable the intelligent contract to perform aging monitoring on the authentication request according to an authentication validity duration corresponding to the authentication level, and before detecting that the authentication validity duration expires, further comprises:

when a secondary authentication request corresponding to the current user is received, detecting whether a block corresponding to the secondary authentication request exists in the block chain account book or not;

and if so, requesting secondary response data from the server and feeding back the secondary response data to the client side requesting the secondary authentication.

4. The method of claim 1, wherein invoking an intelligent contract to enable the intelligent contract to perform aging monitoring on the authentication request according to an authentication validity duration corresponding to the authentication level comprises:

starting to perform time-efficiency monitoring on the authentication request after responding to the authentication request;

if the authentication effective duration corresponding to the authentication level is not expired and the client for receiving the response data stops receiving the data, determining the data transmission duration;

and calling the intelligent contract to calculate a target fee aiming at the data transmission duration and deducting the target fee from the account of the current user.

5. The method of claim 1, wherein the consensus of the authentication request comprises:

and inquiring whether a branch node corresponding to the authentication request exists in the Mercker tree of the block chain account book, and if not, identifying the authentication request.

6. The method of claim 5, wherein after writing the authentication request to a blockchain ledger, further comprising:

determining a branch node corresponding to the authentication request from the Mercker tree;

and feeding back the branch node to the client side sending the authentication request.

7. The method of claim 6, wherein after feeding back the forking node to the client sending the authentication request, further comprising:

and the client generates a new authentication request according to the authentication abstract in the branch node and sends the new authentication request to a background server.

8. The method of claim 1, wherein requesting response data from the server according to the write result comprises:

and judging that the authentication request passes the authentication according to the writing result, and sending a multimedia file request to the server so that the server feeds back a corresponding multimedia file as the response data according to the request content corresponding to the authentication request.

9. The method of claim 8, wherein responding to the authentication request based on the response data comprises:

and feeding back the multimedia file to the client side sending the authentication request so as to enable the client side to render the content to be displayed according to the multimedia file.

10. The method of claim 1, wherein consensus on the authentication request and writing the authentication request to a blockchain ledger comprises:

the authentication request is subjected to consensus through a consensus node and written into a block chain account book; and the ratio between the number of the common nodes and the total number of the nodes in the block chain is in a preset range.

11. The method of claim 10, wherein the consensus on the authentication request by a consensus node and writing the authentication request to a blockchain ledger comprises:

broadcasting the authentication request so that each consensus node calculates an authentication summary of a block to which the authentication request belongs:

determining a consensus result according to the consistency of the authentication abstract calculated by each consensus node;

and if the consensus result accords with a preset result, writing the block into the block chain account book.

12. The method of claim 1, before determining the authentication level corresponding to the current user according to the user identifier extracted from the authentication request, further comprising:

acquiring a recharging record corresponding to the current user, and determining an authentication level corresponding to the current user according to the recharging record;

the authentication level corresponding to the current user is changed along with the change of the recharging record corresponding to the current user, and the authentication level corresponding to the current user is positively correlated with the authentication effective duration corresponding to the current user.

13. An authentication apparatus based on a block chain, comprising:

the request verification unit is used for verifying the legality of the authentication request when the authentication request is received;

the request consensus unit is used for performing consensus on the authentication request and writing the authentication request into a block chain account book when the validity of the authentication request is verified;

the request response unit is used for requesting response data from the server according to the writing result and responding to the authentication request according to the response data;

the time efficiency monitoring unit is used for determining the authentication level corresponding to the current user according to the user identification extracted from the authentication request and calling an intelligent contract so that the intelligent contract carries out time efficiency monitoring on the authentication request according to the authentication effective time length corresponding to the authentication level;

a failure information uplink unit, configured to generate a failure credential for representing that the authentication request is failed when detecting that the authentication valid duration expires, and write the failure credential into the block chain ledger; and the invalid authentication request cannot prove the validity of the current user.

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

15. An electronic device, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the method of any of claims 1-12 via execution of the executable instructions.