CN116319072A - An integrated method of authentication and hierarchical access control based on blockchain technology - Google Patents
An integrated method of authentication and hierarchical access control based on blockchain technology Download PDFInfo
- Publication number
- CN116319072A CN116319072A CN202310526397.7A CN202310526397A CN116319072A CN 116319072 A CN116319072 A CN 116319072A CN 202310526397 A CN202310526397 A CN 202310526397A CN 116319072 A CN116319072 A CN 116319072A
- Authority
- CN
- China
- Prior art keywords
- server
- user
- servers
- registration
- authentication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/105—Multiple levels of security
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
本申请公开了一种基于区块链技术的认证和分级访问控制一体化方法，包括：初始化阶段：所有服务器组成区块链网络，所有的服务器共同协商系统参数；用户注册阶段：用户在向任意服务器缴纳费用，并在该服务器上完成注册，服务器给用户颁发凭证，并将用户信息储存到区块链的公有账本中；认证阶段：用户与服务器进行双向认证，服务器认证用户能够访问的权限，用户认证服务器的正确性。本申请提供了一种能够避免非法服务器恶意窃取用户信息的认证和分级访问控制一体化方法。
This application discloses an integrated method of authentication and hierarchical access control based on blockchain technology, including: initialization stage: all servers form a blockchain network, and all servers jointly negotiate system parameters; user registration stage: users register with any The server pays the fee and completes the registration on the server. The server issues a certificate to the user and stores the user information in the public ledger of the blockchain; the authentication stage: the user and the server perform two-way authentication, and the server authenticates the user's access rights. The user authenticates the correctness of the server. This application provides an integrated method of authentication and hierarchical access control that can prevent illegal servers from maliciously stealing user information.
Description
Technical Field
The application relates to the technical field of information service, in particular to an authentication and hierarchical access control integrated method based on a blockchain technology.
Background
The mobile cloud service is the latest form of fusion development of the mobile internet and cloud computing, and aims to provide various comprehensive services of cloud computing for end users by taking a mobile intelligent terminal as an information access port through the mobile internet. Because the resources that can be provided by the suppliers of the servers of the cloud services are different, when the user uses the cloud service, the user needs to complete registration on the servers of the different cloud services to be able to enjoy the corresponding rights, and the mode is very complicated for the user.
In the related art, servers of multiple providers form a centralized mobile cloud service system, and after a user completes information registration on one of the servers, the user does not need to complete registration on the rest of the servers. However, in a centralized mobile cloud service system composed of a plurality of servers, the server and the user authentication method are constructed on the basis of identity information authentication between an individual server and a user. In the mode, only the authentication of the centralized server to the user information is concerned, and the authentication of the user to the server information is not concerned, so that the user can easily send the identity information of the user to an illegal server when the user is connected to the centralized mobile cloud service system, and the information security of the user is threatened.
Disclosure of Invention
The content of the present application is intended to introduce concepts in a simplified form that are further described below in the detailed description. The section of this application is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
In order to solve the technical problems mentioned in the background art, some embodiments of the present application provide the following technical solutions: an authentication and hierarchical access control integrated method based on a blockchain technology comprises the following steps:
an initialization stage: all servers form a block chain network, and all servers negotiate system parameters together;
a user registration stage: the user pays fees to any server, registration is completed on the server, the server issues certificates to the user, and user information is stored in a public account book of the blockchain;
authentication: the user performs bidirectional authentication with the server, the server authenticates the authority which can be accessed by the user, and the user authenticates the correctness of the server;
a fund settlement stage, wherein all servers forming the blockchain network periodically settle fees;
access right updating stage: the registered user updates the authority information at an arbitrary server.
The beneficial effects of this application lie in:
according to the method and the system, the servers are connected with the blockchain network information, so that when all the servers upload the registration information of the user to the blockchain network, the registration information stored in the blockchain can be subjected to decentralized management under the condition that the registration information cannot be tampered, the user can finish registration of any server and upload the registration information in the blockchain network, or when other servers are accessed, the registration is not needed, and the other servers only need to call the registration information of the user on the blockchain network; when the registered user accesses the server, the server authenticates the user, and the user authenticates the server, so that the problem that the user information is stolen by an illegal server because the user does not authenticate the server when the user performs information interaction between the server is avoided. Therefore, the technical scheme provided by the application can also avoid the problem that the information security is threatened because the user cannot identify the illegal server on the basis of providing the centralized cloud service system for the user. Meanwhile, the public account book is stored in the blockchain, so that the registration information stored in the public account book cannot be tampered, and the server and the user can monitor the information stored in the public account book, so that the registration information of the user is prevented from being invalid; meanwhile, the information stored in the public account book is the registration information generated by the public key, so that the information is generated by the public key in the clear text and does not reveal the specific information of the user, and the server can update the authority information of the user stored in the private account book in time according to the registration information published in the blockchain.
In summary, the beneficial effects of the present application include the following:
single point registration: the user can access various servers only by registering once, and the servers upload the registration information of the user to the blockchain commonly maintained by all the servers; the user may then access various different rights servers during the authentication phase.
And (3) bidirectional authentication: the two communication parties need to mutually verify identities, so that illegal users are prevented from disguising as users or disguising as servers to steal user information or server information. Meanwhile, in order to increase reliability of mutual authentication, when the server authenticates the user, the server S j First, the DID of the user is obtained by using the private key i Then the server S j Finding corresponding registration information on the blockchain according to the dynamic pseudonym, and extracting the corresponding public key PK Ui And registration time T 1i . Server S j With PK Ui Verify the signature of the user, if Ver (PK Ui ,S Ui ,DID i ‖Y‖T 3 ) =1, then server S j Will determine user U i Is a legal user. At the time of user authentication of the server, the user calculates V ', if V' =h (PK y Sj ‖DID i ) And checks if it is equal to the received message V, if so, the server S j Is an effective service provider. The probability of a polynomial adversary attempting to forge the identity information of a legitimate user or service provider is negligible due to the non-counterfeitability of the signature, the collision resistance of the hash function, and the difficulty of the deterministic Diffie-Hellman (DDH) problem.
User access rights: the user access rights are stored in the form of promise in a public account book, and because of the disguise of promise, an attacker can obtain the registration information of the user, but cannot infer the specific access rights of the user by using the information.
Linking of transactions: on blockchain networks, registration data is disclosed to all participants, and in order to protect the privacy of the service provider (e.g., target audience, number of users, etc.), a transaction contains promises calculated by the user for each server, regardless of whether the user needs to access the server, in such a way that the authorization information of the server is confused, and an attacker cannot determine whether the server authorizes the access of the user, nor can the attacker obtain the connection between them through a transaction.
User anonymity and non-traceability: during authentication phase, dynamic pseudonym DID is used i Hidden in
Wherein the blind factor is a Diffie-Hellman tuple. Intercept messages { C, Y, T 1i After S, the attacker is due to the lack of the private key SK Uj The identity of the user can only be obtained by solving the computational Diffie-Hellman (CDH) problem, and thus our solution provides user anonymity. On the other hand, since the first authentication random number generated each time is different, the generated message { C ', Y', T 1 'S' are also different. Thus, the attacker cannot decide that the transmitted messages C, C' come from the same user, i.e. that untraceability is achieved.
Hierarchical access control: in the registration stage, the user purchases the corresponding service grade, and registration information is uploaded to the blockchain after verification. When the server detects that the public account book changes, the private account book needs to be updated. During the authentication phase, the server S j Reading registration/update time T from public ledgers and private ledgers, respectively 1i And rights
Checking user U i Whether the access rights of (a) expire. The user cannot access outside the scope of the rights.
Centerless authorization: in our approach, the user can select any one of the service providers to register and update access rights without requiring a central authorization. With the aid of the intelligent contract, checking whether the service fee paid by the user is sufficient or not, and performing financial settlement.
Replay attack: to grant access rights, user U i And a server S j It is necessary to perform twiceAnd (5) message communication. User U i Send login message 1= { C, Y, T 3 S, server S j First through T 4 -T 3 The freshness of the message is checked. Furthermore, based on the non-counterfeitability of the signature, the server S j It can be easily detected whether an illegal user has changed any parameters of the message. Subsequently, the server S j Return message 2= (V). Since the user generates a new first authentication random number y for each session, it must be the current session when they accept each other. Typically, we use the current timestamp and the first authentication nonce to prevent replay attacks.
Simulation attack: to simulate a user, an illegitimate must forge a valid message1, however, it is not feasible due to the non-counterfeitability of the signature. In addition, an illegitimate cannot create a valid message2 on behalf of the server, because it needs to solve Diffie-Hellman (CDH) computational problems without the user's private key and the server's private key, so the solution can resist both user masquerading attacks and server masquerading attacks.
Man-in-the-middle attack: assume that an attacker eavesdrops on message1 and message2 and tries to modify them to form another legitimate message. Based on the above analysis, our solution supports two-way authentication, so that an attacker's modification to message1 and message2 will be detected, meaning that our solution can resist man-in-the-middle attacks.
The communication performance cost is low: according to the technical scheme, the communication performance is excellent, the communication cost is low, the calculation time of a user is about 40.327 ms in the test of the authentication stage, the calculation time of a service provider is about 6.509 ms, the calculation time is short, and the expected requirement is met. The reason is that the technical scheme provided by the application avoids the most time-consuming point-to-point hash function or a plurality of point multiplication operations. Message 1= { C, Y, T in terms of communication cost 3 S } requires (160+320+32+320) = 832b and message 2= (V) requires 160b, these two values are added, the total communication overhead of our scheme in authentication phase is 992 bits, and the proposed scheme only requires two rounds of message communication with minimum information quantity in related technology, so that the scheme is communicatedThe information cost is low.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this application, are included to provide a further understanding of the application and to provide a further understanding of the application with regard to the other features, objects and advantages of the application. The drawings of the illustrative embodiments of the present application and their descriptions are for the purpose of illustrating the present application and are not to be construed as unduly limiting the present application.
In addition, the same or similar reference numerals denote the same or similar elements throughout the drawings. It should be understood that the figures are schematic and that elements and components are not necessarily drawn to scale.
In the drawings:
FIG. 1 is a schematic diagram of a blockchain-based authentication system in some embodiments of the present application;
FIG. 2 is a schematic diagram illustrating a registration phase information flow based on an authentication system according to some embodiments of the present application;
FIG. 3 is a schematic diagram of a simplified public ledger on a blockchain;
FIG. 4 is a schematic diagram of a public ledger on a blockchain;
fig. 5 is a schematic diagram of a private ledger.
Detailed Description
Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.
It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings. Embodiments of the present disclosure and features of embodiments may be combined with each other without conflict.
The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.
Corner mark description: in the formulas of the application documents, when some formulas are expressed as corner marks, it should be understood that they should also belong to the same parameter although they are not explicitly identified above and below. For example:
PK sj =g SKSj in the formula, the superscript SKSj of g is SK Sj For ease of representation, in SK Sj When the upper label or the lower label is used, the upper and lower label relation of SK and Sj is hidden. The same is true in the remaining examples of the application.
For example g SKUi 、
、Y SKSj 、g ajk h rjk 、g SKUi’ 、
。
Referring to fig. 1, an authentication and hierarchical access control integrated system based on a blockchain technology includes a blockchain network, a number of servers, and a number of users accessing cloud services.
All servers constitute an MSP, which includes a server S 1 … Server S j … Server S m Wherein any one of the servers is denoted as server S j The method comprises the steps of carrying out a first treatment on the surface of the For any one of the servers S j The remaining servers are denoted as servers S k ，k∈[1,j-1]∪[j+1,m]For each server S j Are all generated with corresponding identity SIDs j 。
For each user accessing MSP, act as user U 1 User U 2 … user U i … user U t Wherein any one user is user U i ，U t For accessing the last subscriber of the MSP.
Referring to fig. 2, the scheme is implemented by the following scheme:
an initialization stage: several servers form a blockchain network, and all servers negotiate system parameters together.
A user registration stage: the user pays the fee to the server, the user finishes registering on the server, after the registering is finished, the server issues the certificate to the user, and the user information is stored in the public account book of the blockchain.
Authentication: the user performs two-way authentication with the server, which authenticates the user to access those resources, and the user authenticates the correctness of the server.
Fund settlement stage: to ensure that the server is able to obtain the user's service fee, all transactions are funded at intervals.
Access right updating stage: the user can update the authority on each server at any time on any server.
Specifically, the method for integrating authentication and hierarchical access control based on the blockchain technology comprises the following steps (it should be noted that there is no strict sequence relationship between the following steps, and the steps can be exchanged in any order).
Step 1 is the initialization phase of the present application.
Step 1: all servers negotiate to select a q-th order cyclic group G, a hash function H: {0,1} → {0,1} 1 And two generator elements G and h of group G, where l represents the number of bits output by the hash function, and then each server S j Generating a public-private key pair, wherein the private key is SK Sj The public key being PK sj ，SK Sj ∈Z q * ,PK sj =g SKSj ；Z q * Is a q-order cyclic group.
Step 2 is the user registration phase of the present application.
Step 2 comprises the following steps:
step 21: generating a unique identity mark by a user, generating a dynamic pseudonym through a public key, and generating a permission sum and a permission triplet required by each server according to the permission required by the user on each server; registration information is then generated that includes the dynamic pseudonym, the identity, the public key of the user, the sum of rights required on the respective servers, the permission triplets, the zero knowledge protocol that proves the private key, the registration request, the registration signature, and the registration time.
step 211: user U i Generating unique identification PID i And private key SK Ui ，SK Ui ∈Zq * And by private key SK Ui Generating dynamic pseudonym DID i Public key PK Ui ，PK Ui = g SKUi ，DID i =H（PK Ui ）；H（PK Ui ) Is PK Ui Is used to generate the hash value of (a).
Wherein, the identity mark PID i Is a string of randomly generated numbers.
Step 212: user U i For each server S j All select the first random number r ij And a second random number
，
E Zq, where ∈>
Satisfy the condition of->
；
Definition of the definition
User U i According to the server S j Definition of application rights on->
，
Representing user U i At server S j Authority on the platform;
user U i Rights sum to P on all servers i , 
。
Step 213: user U i Calculation of
；
User U i Calculation pair
For determining the promise of the user U i At the server S j The required rights;
user U i Definition of the definition
and Lij ={comm ij ，X ij ，M ij }；
wherein ,
M ij for user U i At registered server S j A first permission parameter on the first permission parameter;
comm ij for user U i At registered server S j A second permission parameter on the first permission parameter;
X ij for user U i At registered server S j A third authority parameter on the first authority parameter;
L ij is user U i At the server S j Authority triples on the file;
II is a connector, and B is an exclusive OR symbol,
is->
Is used to generate the hash value of (a).
Step 214: user U i Running zero knowledge proof protocol
Attesting to his temporary key SK Ui ，
step 215: by usingHousehold U i Generating a registration signature S Ui ，S Ui =Sig Ui （SK Ui ，DID i ‖PK Ui ‖SID j ‖P i ‖L i1 ‖…L im ‖T 1i ) Then transmits registration information including the registration request to the server S through the secure channel j The registration information is:
T 1i is the current time of execution of step 215, T 1i For registration time reg is a registration request.
Step 22: after receiving the registration information, the server verifies the dynamic pseudonym, the public key of the user, the authority sum required on each server, the authority triplets, the zero knowledge protocol for proving the private key, the registration signature and the registration time in the registration information, and if the verification is successful, the server sends a verification request to the rest of servers.
Step 22 specifically includes the steps of:
step 221: server S j Verifying the registration time T 1i If the current system time and registration time T 1i If the threshold is exceeded, the verification fails, the registration information fails, and otherwise, step 222 is executed;
step 222: server S j Verification of zero knowledge proof
If the verification fails, the registration information fails, otherwise step 223 is performed;
step 223: server S j Verification Ver (PK) Ui ，S Ui ，DID i ‖PK Ui ‖SID j ‖P i ‖L i1 ‖…‖L im ‖T 1i ) If it is equal to 1, if it is not equal to 1, the verification fails, the registration information fails, otherwise step 224 is executed;
wherein, ver is the first verification parameter;
step 224: clothes with a pair of wearing articlesServer S j Verification
If not, the verification fails, the registration information fails, otherwise, step 225 is performed,/->
Is->
Is a hash value of (2);
step 225: server S j Verifying whether the user U has been registered on the private ledger i If registration is already done, the authentication fails and the registration information is invalid, otherwise step 226 is performed.
Step 226: server S j Verification
Whether or not it is true, if not, the authentication fails, the registration information fails, otherwise, step 227 is performed, wherein g Pi Is the second verification parameter.
Step 227: server S j Calculation of
Then verify->
If yes, if not, the verification fails, the registration information fails, otherwise, step 228 is executed; wherein (1)>
Is a third verification parameter;
step 228: server authentication user U i If the correct fee is paid, if the paid fee is not right, the verification fails, the registration information fails, otherwise step 229 is performed;
step 229: server S j Calculate a verification signature S Sj ，S Sj =Sig sj （SK Sj ，DID i ‖PK Ui ‖P i ‖L i1 ‖L i2 ‖…L im ‖T 2 ) Then the server S j Generating a verification request, wherein the verification request is { DID } i ，PK Ui ，P i ,L i1 ，L i2 ，…L im ,S Ui ，S Sj ，T 2 }，T 2 For the current time of execution of step 229, T 2 Representing the time of generation of the authentication signature and broadcasting the authentication request to other servers S on the blockchain K ，K∈[1,j-1]∪[j+1，m]。
Step 23: after receiving the verification request and reaching consensus, the rest servers succeed in registering the user, the servers return registration time and certificates to the user, the servers upload dynamic pseudonyms, public keys, authority sum required on each server and authority triples of the user to a public account book, and simultaneously each server records the identity identification of the user and the authority on the user into a private account book of the user, and the user stores the dynamic pseudonyms, the identity identification, the public keys and the private keys of the user.
Step 23 specifically includes the following steps:
step 231: server S k Respective calculations
and
，
Judging
And comm in message ik If so, all servers agree to upload the registration information to the blockchain, server S j Upload { DID i ，PK Ui ，SID j ，P i ，L i1 ，L i2 ，…L im ，S Ui ，S Sj ，T 2 Public ledger to blockchain, (as shown in fig. 3 and 4), while each server will (PID) i ，
) Deposit into its own private ledger (as shown in figure 5).
wherein ,
for user U i At the server S k The authority of the application;
for any one server S j User U i Are given a first random number r ij R is then ik Is user U i For the server S k A first random number selected;
M ik is user U i At the server S j At the time of registration, at the server S k A first permission parameter on the first permission parameter;
comm ik is user U i At the server S j At the time of registration, at the server S k A second permission parameter thereon.
X ik Is user U i At the server S j At the time of registration, at the server S k The third authority parameter is according to the formula
Calculating to obtain;
User U i At any one of the servers S j When registering, user U i A first random number is generated for all servers, so for user U i Selected registration server S j In other words, the rest servers are S k While these servers S k User U i Also for this, a corresponding first random number is generated, these servers S for ease of differentiation k By user U i A defined first random number, denoted as a first random number r ik Correspondingly, for user U i For each server S j Can calculate the second authority parameter comm ij So for user U i Selected registration server S j In other words, the rest servers are S k While these servers S k User U of (2) i Corresponding second authority parameters are also generated for the servers S for convenience of distinguishing k By user U i The second authority parameter comm is defined and recorded as comm ik 。
Step 232: server S j Issuing vouchers and T 2 To the user, indicating the success of registration, user U i Storing PID i ，DID i ，PK Ui ，SK Ui 。
Step 3 is an authentication stage of the present application;
the step 3 is as follows: when a registered user accesses any server, the user generates an authentication signature of the user through a private key and sends an authentication request containing the authentication signature to the server to be accessed; the server verifies the authentication request according to the public key corresponding to the public account book, and meanwhile, the server returns verification information generated through the private key of the server to the user, and the user verifies the verification information through the public key of the server.
Step 3 comprises the following steps:
step 31: user U i Selecting y ε Zq * And Y is calculated by Y, y=g y Calculation of
User U i Generating an authentication signature s=sig Ui (SK Ui ，DID i ‖Y‖T 3 ) User U i Transmitting authentication request { C, Y, T over public channel 3 S } to server S j, wherein T3 Is the current time of step 31 execution, T 3 The generation time of the authentication signature is represented by Y being a first authentication random number, Y being a second authentication random number generated randomly in the user authentication phase, and C being an authentication parameter.
Step 32: server S j According to DID i Querying public account book on blockchain to find user U i Public key PK corresponding in registration phase Ui 、L ij Registration time T 1i Server S j Then according to the private account book
Judging whether [ T ] is satisfied 4 -T 1i ]＜
, wherein T4 For the current time of step 32 execution, if not, indicating that the user's VIP has expired, the user is only allowed to access free resources, T 1i For user U i Is used for the registration time of (a).
Step 33: server S j Returns verification information V, v=h (Y SKSj ‖DID i ) To user U i User U i The verification parameter V' is calculated,
and verifying whether V' is equal to V, if so, indicating that the user successfully verifies the server, otherwise, verifying failure.
Step 4 is the fund settlement stage of the present application.
Step 4 comprises the following steps:
step 41: server S j Calculation of
Obtaining the number of days authorized to the user per transaction per se +.>
，
The service fee which is required to be obtained in each transaction can be obtained by multiplying the unit price.
Step 42: each server S j Calculate the rest of the servers S k Among registered users, the server S j The service charge to be charged, k.epsilon.1, j-1]∪[j+1,m];
Server S j Calculate all users at server S k Registered server S j Days of authorization on a jk And the sum r of the corresponding first random numbers jk Server S j Multiplying by a jk Is obtained at the server S k Service fee at, wherein:
a jk is that all users are in the server S k Registered server S j Sum of the number of days authorized above;
r jk is that all users are in the server S k When registering, the server S is given j A first random number r is set ij Is the sum of (3);
calculation server S k Homomorphism of commitments in a registration transaction is for a jk Is a commitment to (1),
comm ajk is that all users are in the server S k At the time of registration, at the server S j The product of the set second authority parameters;
server S j Disclosure a jk Sum r of the first random number jk 。
Because for any one server S j The rest of the servers S K Registered users can also applyPlease server S j So for any one server S j All that is required is to calculate at the remaining server S k Sum of authorized days registered on.
Step 43: validating each server S j Whether the issued service charge is correct, if each server S j If the issued service fee is correct, the service fee is settled for all servers, if the server with incorrect issued service fee exists, the server with incorrect issued service fee is found, and the service fee is settled for the rest servers.
Step 43 specifically includes the following steps:
step 431: presetting a smart contract set () which collects a sent by all servers jk and rjk When the intelligent contract is triggered, j is E [1, m]，k∈[1,j-1]∪[j+1,m]。
Step 432: the Smart contract Settlement () calculates the total days pay for all server registrations k The total amount that the corresponding server should pay can be reached by multiplying the unit price.
Step 433: smart contract Settlement () authentication pay k And (3) with
Whether or not they are equal, k E [1, j-1 ]]∪[j+1,m]If the service fee is equal, it means that there is no server lie, the corresponding service fee is settled for all servers, and if the service fee is not equal, a is provided for each server jk and rjk Authentication is performed to find lie servers.
Step 434: the smart contract set () is for each server S in turn j Provided a jk R jk Verification
And g is equal to ajk h rjk If not, indicate a jk Correct, server S j If not, the server is stated to lie.
g ajk For the first settlement parameter, h rjk As a second settlement parameter, 
as a third settlement parameter,
is that all users are in the server S k At the time of registration, at the server S j The product of the set second authority parameters;
step 5 is the rights update phase of the present application.
The step 5 specifically comprises the following steps:
step 51: and the user regenerates a new public and private key pair and a new dynamic pseudonym, and sends authority update information to any server nearest to the user according to the authority required by the new application.
Step 511: user U i Generating a new private key SK Ui ’∈Z q * And generates a new public key PK Ui ' and New dynamic pseudonym DID i ’，PK Ui ’=g SKUi’ ,DID i ’ =H（PK Ui ’）。
Step 512: user U i For each server S j All select a new first random number r ij ' and new second random number
, r ij ’∈ Z q * ,
∈ Z q *, wherein ,rij ' satisfy Condition>
Definitions->
，j∈[1，m]。
Step 513: user U i According to the server S j Rights definition for the last new application
，
Is the authority required by the new application of the user, and the user calculates
M ij ' for user U i Server S applying for rights update j Updating parameters by the first authority;
user U i The sum of rights to be updated on all servers is denoted as P i ’，
；
User U i Calculation pair
For determining the promise of the user U i At the server S j The required rights;
user U i Definition of comm ij ’=g pij’ h rij’ 
,L ij ’={ comm ij ’， X ij ’，L ij ’}，
comm ij ' for user U i Server S updated in authority j Updating parameters by the second authority; x is X ij ' for user U i At server S of authority update j The third authority on the server updates parameters L ij ' is user U i When the authority is updated, the server S j And authority triples.
Step 514: user U i Run zero knowledge proof protocol, prove his temporary key SK Ui ’，
Step 515: user U i Generating rights update signature S' Ui , S’ Ui= Sig Ui （SK Ui ’，DID i ’‖PK Ui ’‖SID j ‖P i ’‖L i1 ’‖…L im ’‖T 5 ) User U i Sending rights update information
For any nearest server, T 5 The current time performed for step 515 represents the generation time of the rights update information.
Step 52: after the server receives the rights update information, the new dynamic pseudonym in the rights update information, the new public key of the user, the new rights sum required on each server, the new rights triplet, the zero knowledge protocol of the new attestation private key, the rights update signature, and the generation of the rights update information
Time is verified, and finally, new authority sum is verified
And if the received money corresponds to the received money, the server generates a permission update request and broadcasts the permission update request to the rest servers if the content is verified successfully.
Step 52 specifically includes the steps of:
step 521: server S receiving update request j Validating new zero knowledge proof protocol
Whether the rights update signature is correct or not +.>
Whether or not to establish;
step 522: server S receiving update request j Calculation of
and
And verify
And->
If it is true, if at least one of the equations is not true, the authentication fails, the update request fails, and if both are true, the server S j Computing authority verification signature S Sj ’， S Sj ’=Sig（SK Sj ，DID i ’‖PK Ui ’‖SID j ’‖P i ’‖L i1 ’‖L i2 ’‖…‖L im ’‖T 6 ），T 6 Is the current time.
Step 523: if the verification results of steps 521-522 are equal, and the new authority sum P i ' correspond to the received money, the server S j Generating a permission update request, wherein the permission update request is as follows: { DID i ’‖ PK Ui ’‖SID j ‖p i ’ ‖L i1 ’‖L i2 ’‖…‖L im ’‖T 6 And broadcasting entitlement update requests to other servers S on the blockchain k 。
Step 523: after receiving the permission update request, the rest servers verify the permission update request, after all the servers verify the permission update request, and after the permission update request passes the verification, the permission update information submitted by the user is uploaded to a public account book of the blockchain, and each server updates own private account book and returns permission update time and permission update certificates to the user.
Specifically, the other servers that received the rights update request each calculate
And verify->
If so, the servers agree on each other. Server S j Uploading authority update information to public account book of blockchain, and finally server S j Return rights update time T 6 And authority update credentials to the user, indicating successful upload, user U i Preserving DID i ’，PK Ui ’，SK Ui ' replace DID i ，PK Ui ，SK Ui The method comprises the steps of carrying out a first treatment on the surface of the The rights update information uploaded to the blockchain is:
{DID i ’‖PK Ui ’ ‖SID j ‖P i ’‖L i1 ’‖L i2 ’‖…‖L im ’‖T 6 }。
step 54: when detecting the change of the public account, each server updates its private account, server S j By DID i Inquiring public account book to find corresponding registration time T 1i Updating in private ledgers
：T 1i For user U i Is used for the registration time of (a).
The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above technical features, but encompasses other technical features formed by any combination of the above technical features or their equivalents without departing from the spirit of the invention. Such as the above-described features, are mutually substituted with (but not limited to) the features having similar functions disclosed in the embodiments of the present disclosure.
Claims (10)
1. An authentication and hierarchical access control integrated method based on a blockchain technology comprises the following steps:
an initialization stage: all servers form a block chain network, and all servers negotiate system parameters together;
a user registration stage: the user pays fees to any server, registration is completed on the server, the server issues certificates to the user, and user information is stored in a public account book of the blockchain;
authentication: the user performs bidirectional authentication with the server, the server authenticates the authority which can be accessed by the user, and the user authenticates the correctness of the server;
a fund settlement stage, wherein all servers forming the blockchain network periodically settle fees;
access right updating stage: the registered user updates the authority information at an arbitrary server.
2. The blockchain technology-based authentication and hierarchical access control integrated method of claim 1, wherein: in the initialization phase:
all servers constitute an MSP, which includes a server S 1 … Server S j … Server S m Wherein any one of the servers is denoted as server S j ；
For any one of the servers S j The remaining servers are denoted as servers S k ，k∈[1,j-1]∪[j+1,m]For each server S j Are all generated with corresponding identity SIDs j ；
For each user accessing MSP, act as user U 1 User U 2 … user U i … user U t Wherein any one user is user U i ；
All servers negotiate to select a q-th order cyclic group G, a hash function H: {0,1} → {0,1} 1 And two generator elements G and h of group G, where l represents the number of bits output by the hash function, and then each server S j Generating public-private key pairs, SK Sj ∈Z q * ,PK Sj =g SKSj ，SK Sj Is a serverS j Generated private key, PK sj For the server S j Generated public key, Z q * Generating elements for q-th order loops.
3. The blockchain technology-based authentication and hierarchical access control integrated method of claim 2, wherein: the user registration phase includes the steps of:
step 21: generating a unique identity mark by a user, generating a dynamic pseudonym through a public key, and generating a permission sum and a permission triplet required by each server according to the permission required by the user on each server; then generating registration information including dynamic pseudonyms, identity marks, public keys of users, authority sum required on each server, authority triples, zero knowledge protocols for proving private keys, registration requests, registration signatures and registration time;
step 22: after receiving the registration information, the server verifies the dynamic pseudonym, the public key of the user, the authority sum required on each server, the authority triples, the zero knowledge protocol for proving the private key, the registration signature and the registration time in the registration information, and if the verification is successful, a verification request is sent to other servers;
step 23: after receiving the verification request and achieving consensus, the rest servers successfully register the user, the servers return registration time and credentials to the user, the servers upload dynamic pseudonyms, public keys, authority sum required on each server and authority triples of the user to a public account book, and each server records the identity of the user and the authority on the server to a private account book of the server;
the user stores the dynamic pseudonym, the identity mark, the public key and the private key of the user.
4. A blockchain technology-based authentication and hierarchical access control integration method as in claim 3, wherein: in step 21, the registration information is generated by:
step 211: user U i Generating unique identification PID i And private key SK Ui ，SK Ui E Zq, and by private key SK Ui Generating dynamic pseudonym DID i Public key PK Ui ，PK Ui = g SKUi ，DID i =H（PK Ui ) The method comprises the steps of carrying out a first treatment on the surface of the Wherein, the identity mark PID i Is a string of randomly generated numbers, H (PK Ui ) Is PK Ui Is a hash value of (2);
step 212: user U i For each server S j All select the first random number r ij And a second random number
，
∈Zq * ，r ij E Zq, where r ij Satisfy the condition of->
；
Definition of the definition
User U i According to the server S j Definition of application rights on->
，
Representing user U i At server S j Authority on the platform;
user U i Rights sum to P on all servers i , 
；
，
Step 213: user' sU i Calculation of
；
User U i Calculation pair
For determining the promise of the user U i At the server S j The required rights;
user U i Definition of the definition
and Lij ={comm ij ，X ij ，M ij }；
wherein ,
M ij for user U i At registered server S j A first permission parameter on the first permission parameter;
comm ij for user U i At registered server S j A second permission parameter on the first permission parameter;
X ij for user U i At registered server S j A third authority parameter on the first authority parameter;
L ij is user U i At the server S j Authority triples on the file;
II is a connector, and B is an exclusive OR symbol,
is->
Is a hash value of (2);
step 214: user U i Running zero knowledge proof protocol
Attesting to his temporary key SK Ui ，
step 215: user U i Generating a registration signature S Ui ，S Ui =Sig Ui （SK Ui ，DID i ‖PK Ui ‖SID j ‖P i ‖L i1 ‖…L im ‖T 1i ) Then transmits registration information including the registration request to the server S through the secure channel j The registration information is:
T 1i is the current time at which step 215 is performed, T 1i For registration time reg is a registration request.
5. A blockchain technology-based authentication and hierarchical access control integration method as in claim 3, wherein: the server that receives the registration information verifies the registration information including the steps of:
step 221: server S j Verifying the registration time T 1i If the current system time and registration time T 1i If the threshold is exceeded, the verification fails, the registration information fails, and otherwise, step 222 is executed;
step 222: server S j Verification of zero knowledge proof
If the verification fails, the registration information fails, otherwise step 223 is performed;
step 223: server S j Verification Ver (PK) Ui ，S Ui ，DID i ‖PK Ui ‖SID j ‖P i ‖L i1 ‖…‖L im ‖T 1i ) If it is equal to 1, if it is not equal to 1, the verification fails, the registration information fails, otherwise step 224 is executed; wherein, ver is the first verification parameter;
step 224: server S j Verification
If so, if not, the authentication fails, the registration information fails, otherwise step 225 is performed,
is that
Is a hash value of (2);
step 225: server S j Verifying whether the user U has been registered on the private ledger i If so, the verification fails and the registration information fails, otherwise, step 226 is performed;
step 226: server S j Verification
Whether or not the verification is true, if not, the verification is failed, the registration information is invalid, otherwise, the step 227 is executed; g Pi Is a second verification parameter;
step 227: server S j Calculation of
Then verify->
If yes, if not, the authentication fails, the registration information fails, otherwise, step 228 is performed,/if not>
Is a third verification parameter;
step 228: server authentication user U i If the correct fee is paid, if the paid fee is not right, the verification fails, the registration information fails, otherwise step 229 is performed;
step 229: server S j Calculate a verification signature S Sj ，S Sj =Sig sj （SK Sj ，DID i ‖PK Ui ‖P i ‖L i1 ‖L i2 ‖…L im ‖T 2 ) Then the server S j Generating a verification request, wherein the verification request is { DID } i ，PK Ui ，P i ,L i1 ，L i2 ，…L im ,S Ui ，S Sj ，T 2 }，T 2 For the current time of execution of step 229, T 2 Representing the time of generation of the authentication signature and broadcasting the authentication request to other servers S on the blockchain K ，K∈[1,j-1]∪[j+1，m]。
6. A blockchain technology-based authentication and hierarchical access control integration method as in claim 3, wherein: the other servers receive the verification request and perform verification so that the user registration is successful, and the method comprises the following steps:
step 231: server S k Respective calculations
and
，
Judging
Comm in authentication request ik If so, all servers agree to upload the registration information to the blockchain, server S j Upload { DID i ，PK Ui ，SID j ，P i ，L i1 ，L i2 ，…L im ，S Ui ，S Sj ，T 2 Public account verification request book of block chain, while each server will (PID i ，
) Storing the private account book of the user;
wherein ,
for user U i At the server S k The authority of the application;
for any one server S j User U i Are given a first random number r ij R is then ik Is user U i For the server S k A first random number selected;
M ik is user U i At the server S K A first permission parameter on the first permission parameter;
comm ik is user U i At the server S K A second permission parameter on the first permission parameter;
X ik is user U i At the server S K The third authority parameter is according to the formula
Calculating to obtain;
step 232: server S j Issuing vouchers and T 2 To user U i Indicating successful registration, user U i Storing PID i ，DID i ，PK Ui ，SK Ui 。
7. The blockchain technology-based authentication and hierarchical access control integrated method of claim 2, wherein: the authentication phase comprises the following steps:
step 31: user U i Selecting Y e Zq, and calculating Y by Y, y=g y Calculation of
User U i Generating an authentication signature S, s=sig Ui (SK Ui ，DID i ‖Y‖T 3 ) User U i Transmitting authentication request { C, Y, T over public channel 3 S } to server S j, wherein ,T3 Is the current time of step 31 execution, T 3 The generation time of the authentication signature is represented, Y is a first authentication random number, the generation is performed randomly in a user authentication stage, Y is a second authentication random number, the generation is performed through the first authentication random number Y, and C is an authentication parameter;
step 32: server S j According to DID i Querying public account book on blockchain to find user U i Public key PK corresponding in registration phase Ui 、L ij Registration time T 1i Server S j Then according to the private account book
Judging whether [ T ] is satisfied 4 -T 1i ]＜
，
wherein ,T4 For the current time of step 32 execution, if not, indicating that the user's VIP has expired, the user is only allowed to access free resources, T 1i For user U i Is a registration time of (a);
step 33: server S j Returns verification information V, v=h (Y SKSj ‖DID i ) To user U i User U i The verification parameter V' is calculated,
verifying whether V' and V are equal or not, if so, the user successfully verifies the server, otherwise, the verification fails.
8. A blockchain technology-based authentication and hierarchical access control integration method as in claim 3, wherein: the fund settlement stage comprises the following steps:
step 41: server S j Calculation of
Obtaining the number of days authorized to the user per transaction per se +.>
，
The service charge which is needed to be obtained in each transaction can be obtained by multiplying the unit price;
step 42: each server S j Calculate the rest of the servers S k Among registered users, the server S j The service charge to be charged, k.epsilon.1, j-1]∪[j+1,m]；
Server S j Calculate all users at server S k Registered server S j Day of authorization on
And the sum r of the corresponding first random numbers jk Server S j Multiplying by a jk Is obtained at the server S k Service fee at, wherein:
a jk is that all users are in the server S k Registered server S j Sum of the number of days authorized above;
r jk is that all users are on the serverS k When registering, the server S is given j A first random number r is set ij Is the sum of (3);
calculation server S k Homomorphism of commitments in a registration transaction is for a jk Is a commitment to (1),
comm ajk is that all users are in the server S k At the time of registration, at the server S j The product of the set second authority parameters;
server S j Disclosure a jk Sum r of corresponding first random numbers jk ；
Step 43: validating each server S j Whether the issued service charge is correct, if each server S j If the issued service fee is correct, the service fee is settled for all servers, if the server with incorrect issued service fee exists, the server with incorrect issued service fee is found, and the service fee is settled for the rest servers.
9. The blockchain technology-based authentication and hierarchical access control integrated method of claim 8, wherein: step 43 comprises:
step 431: presetting a smart contract set () which collects a sent by all servers jk and rjk When the intelligent contract is triggered, j is E [1, m]，k∈[1,j-1]∪[j+1,m]；
Step 432: the Smart contract Settlement () calculates the total days pay for all server registrations k The total amount which the corresponding server should pay can be reached by multiplying the unit price;
step 433: smart contract Settlement () authentication pay k And (3) with
Whether or not they are equal, k E [1, j-1 ]]∪[j+1,m]If the two types are equal, the server is not in lie, and all the servers are givenThe server settles the corresponding service fee, and if not, a is provided for each server jk and rjk Verifying to find a lie-spreading server;
step 434: the smart contract set () is for each server S in turn j Provided for
and
Verification of
And->
Whether or not to be equal, if so, indicate a jk Correct, server S j If not lie, otherwise, the server is stated to lie,
g ajk for the first settlement parameter, h rjk As a second settlement parameter,
as a third settlement parameter,
at server S for all users k Com on ij Is a product of (a) and (b).
10. The blockchain technology-based authentication and hierarchical access control integrated method of claim 2, wherein:
the authority updating stage comprises the following steps:
step 51: the user regenerates a new public and private key pair and a dynamic pseudonym, and sends authority update information to any server nearest to the user according to the authority required by the new application;
step 52: after the server receives the authority updating information, verifying the dynamic pseudonym, the public key of the user, the authority sum, the authority triples, the zero knowledge protocol for proving the private key, the authority updating signature and the registration time required by each server in the authority updating information, and finally verifying whether the authority sum corresponds to the received money or not, if the verification of the contents is successful, generating an authority updating request by the server, and broadcasting the authority updating request to other servers;
step 53: after receiving the permission update request, the rest servers verify the permission update request, and after all the servers verify the permission update request and pass the verification, the permission update information submitted by the user is uploaded to a public account book of the blockchain; each server updates its own private ledger and returns the rights update time and rights update credentials to the user.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310526397.7A CN116319072B (en) | 2023-05-11 | 2023-05-11 | An integrated method of authentication and hierarchical access control based on blockchain technology |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310526397.7A CN116319072B (en) | 2023-05-11 | 2023-05-11 | An integrated method of authentication and hierarchical access control based on blockchain technology |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116319072A true CN116319072A (en) | 2023-06-23 |
| CN116319072B CN116319072B (en) | 2023-07-21 |
Family
ID=86799841
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310526397.7A Active CN116319072B (en) | 2023-05-11 | 2023-05-11 | An integrated method of authentication and hierarchical access control based on blockchain technology |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116319072B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117254982A (en) * | 2023-11-20 | 2023-12-19 | 深圳桑达银络科技有限公司 | Blockchain-based digital identity verification method and system |
| CN118378289A (en) * | 2024-01-12 | 2024-07-23 | 广东职业技术学院 | A method and system for secure access to teaching data |
| CN119922024A (en) * | 2025-04-03 | 2025-05-02 | 西华大学 | Integrated anonymous authentication and hierarchical access method for large model-as-a-service |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101490687A (en) * | 2006-07-07 | 2009-07-22 | 桑迪士克股份有限公司 | Control system and method using identity objects |
| CN109462587A (en) * | 2018-11-09 | 2019-03-12 | 四川虹微技术有限公司 | Block chain is layered common recognition method, block chain network system and block chain node |
| CN109948320A (en) * | 2019-03-22 | 2019-06-28 | 泰康保险集团股份有限公司 | Identity identification managing method, device, medium and electronic equipment based on block chain |
| CN110545169A (en) * | 2019-07-16 | 2019-12-06 | 如般量子科技有限公司 | Block chain method and system based on asymmetric key pool and implicit certificate |
| US20200250177A1 (en) * | 2019-01-31 | 2020-08-06 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing an sql query and filter mechanism for blockchain stored data using distributed ledger technology (dlt) |
| CN113722722A (en) * | 2020-05-25 | 2021-11-30 | 北京北信源软件股份有限公司 | Block chain-based high-security-level access control method and system |
| CN114024690A (en) * | 2020-07-15 | 2022-02-08 | 华为技术有限公司 | Method, device and system for joining domain by device based on block chain |
| CN115413042A (en) * | 2022-08-29 | 2022-11-29 | 西华大学 | Data link safety access control method based on control sequence |
-
2023
- 2023-05-11 CN CN202310526397.7A patent/CN116319072B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101490687A (en) * | 2006-07-07 | 2009-07-22 | 桑迪士克股份有限公司 | Control system and method using identity objects |
| CN109462587A (en) * | 2018-11-09 | 2019-03-12 | 四川虹微技术有限公司 | Block chain is layered common recognition method, block chain network system and block chain node |
| US20200250177A1 (en) * | 2019-01-31 | 2020-08-06 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing an sql query and filter mechanism for blockchain stored data using distributed ledger technology (dlt) |
| CN109948320A (en) * | 2019-03-22 | 2019-06-28 | 泰康保险集团股份有限公司 | Identity identification managing method, device, medium and electronic equipment based on block chain |
| CN110545169A (en) * | 2019-07-16 | 2019-12-06 | 如般量子科技有限公司 | Block chain method and system based on asymmetric key pool and implicit certificate |
| CN113722722A (en) * | 2020-05-25 | 2021-11-30 | 北京北信源软件股份有限公司 | Block chain-based high-security-level access control method and system |
| CN114024690A (en) * | 2020-07-15 | 2022-02-08 | 华为技术有限公司 | Method, device and system for joining domain by device based on block chain |
| CN115413042A (en) * | 2022-08-29 | 2022-11-29 | 西华大学 | Data link safety access control method based on control sequence |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117254982A (en) * | 2023-11-20 | 2023-12-19 | 深圳桑达银络科技有限公司 | Blockchain-based digital identity verification method and system |
| CN117254982B (en) * | 2023-11-20 | 2024-02-23 | 深圳桑达银络科技有限公司 | Digital identity verification method and system based on block chain |
| CN118378289A (en) * | 2024-01-12 | 2024-07-23 | 广东职业技术学院 | A method and system for secure access to teaching data |
| CN119922024A (en) * | 2025-04-03 | 2025-05-02 | 西华大学 | Integrated anonymous authentication and hierarchical access method for large model-as-a-service |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116319072B (en) | 2023-07-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN116319072B (en) | An integrated method of authentication and hierarchical access control based on blockchain technology | |
| Xue et al. | A distributed authentication scheme based on smart contract for roaming service in mobile vehicular networks | |
| CN110138560B (en) | Double-proxy cross-domain authentication method based on identification password and alliance chain | |
| CN112637189A (en) | Multi-layer block chain cross-domain authentication method in application scene of Internet of things | |
| JP4129783B2 (en) | Remote access system and remote access method | |
| CN114565386B (en) | Blockchain escrow transaction method and system for multi-party collaborative privacy protection | |
| Park et al. | A secure incentive scheme for vehicular delay tolerant networks using cryptocurrency | |
| Kumar et al. | Ultra-lightweight blockchain-enabled RFID authentication protocol for supply chain in the domain of 5G mobile edge computing | |
| CN115460016B (en) | Signature-based batch authentication method for blockchain Internet of Vehicles | |
| CN115801260B (en) | A blockchain-assisted cooperative attack-defense game method in an untrusted network environment | |
| Riad et al. | A blockchain‐based key‐revocation access control for open banking | |
| CN117375797A (en) | Anonymous authentication and vehicle information sharing method based on blockchain and zero-knowledge proof | |
| Zhang et al. | Anonymous authentication and information sharing scheme based on blockchain and zero knowledge proof for VANETs | |
| JP2003150735A (en) | Electronic certificate system | |
| RU2007138849A (en) | NETWORK COMMERCIAL TRANSACTIONS | |
| EP4307605B1 (en) | Registering and validating a new validator for a proof-of-origin blockchain | |
| EP4379631A1 (en) | Digital wallet device and dual offline transaction method thereof | |
| CN114726583B (en) | Trusted hardware cross-chain transaction privacy protection system and method based on blockchain distributed identification | |
| CN118316712B (en) | A method for configuring industrial equipment based on a dual-chain architecture | |
| Paliwal et al. | Dynamic private modulus based password conditional privacy preserving authentication and key-agreement protocol for VANET | |
| CN116405219B (en) | Multi-factor internet of things equipment group authentication method for guaranteeing firmware security | |
| CN115913647B (en) | Cross-domain device access control policy enforcement method and device based on blockchain | |
| CN114050930B (en) | A data communication authentication method and system based on industrial Internet cloud computing | |
| CN113468614B (en) | Bulletproofs-based Kerberos cross-domain authentication method | |
| CN117242473A (en) | De-centralized excitation hybrid network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20250515 Address after: 518000 1002, Building A, Zhiyun Industrial Park, No. 13, Huaxing Road, Henglang Community, Longhua District, Shenzhen, Guangdong Province Patentee after: Shenzhen Wanzhida Technology Co.,Ltd. Country or region after: China Address before: 610039 Chengdu City, Jinniu District Province, North Bridge Road, No. Patentee before: XIHUA University Country or region before: China |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20250812 Address after: 315100 Zhejiang Province, Ningbo High-tech Zone, Qingyi Road 215 Lane, Building 3, No. 3-1-1-7 Patentee after: Ningbo Saike Technology Co.,Ltd. Country or region after: China Address before: 518000 1002, Building A, Zhiyun Industrial Park, No. 13, Huaxing Road, Henglang Community, Longhua District, Shenzhen, Guangdong Province Patentee before: Shenzhen Wanzhida Technology Co.,Ltd. Country or region before: China |