A security service management method and system based on blockchain

Abstract

The invention discloses a security service management method and system based on blockchain, and relates to the technical field of blockchain, wherein S1: KDC encrypts the AES key of the participant; S2: KDC sends a registration request, sets the participant information mapping and stores it; S3: the user sends AS_REQ, and the smart contract checks; the KDC authentication server obtains the authentication request message S4: the KDC authentication server generates Kc, tgs, constructs the authentication ticket license, and sends AS_REP to the blockchain; S5: the user sends TGS_REQ, and the smart contract checks; S6: the KDC ticket server generates Kc, v, and constructs ST, and sends TGS_REP to the blockchain; S7: the user generates Ksession, sends an application request transaction, and the smart contract checks; the server obtains AP_REQ; S8: the server sends AP_REP to the blockchain, and the user decrypts and obtains Ksession, and the service session is opened. The invention protects the information security of the user through multiple authentications of identity information, and prevents the leakage of user privacy by using the AES key as a cryptographic scheme, thereby improving security.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and more specifically, to a blockchain-based security service management method and system. Background Art

[0002] With the rise of big data technology, data security has become one of the most widely discussed topics in the research community and security experts today. In a distributed environment, big data is developing rapidly, some workstations may be installed in unsafe places, and users are not completely trustworthy. Clients need to authenticate when logging in, so users must obtain a license issued by the authentication server before they can use the services on the target server.

[0003] Kerberos, as an authentication protocol, is widely used in the big data ecosystem and plays a role in the management of security services within the domain. Big data systems such as Apache Hadoop rely on the Kerberos protocol for user identification and authentication. Although Kerberos plays an important role in authentication, some of its problems, such as single point failure caused by centralization, replay attacks, offline password guessing attacks, and DDos, have not been well resolved. In addition, the currently popular authentication and authorization protocols are centralized, which brings additional security issues, such as personal data leakage, unauthorized access, and identity theft.

[0004] There are many studies that have proposed improvements based on the Kerberos protocol. Wang et al. improved it based on dynamic passwords and Diffie-Hellman secure key exchange; Du et al. improved the traditional Kerberos based on AES keys based on dynamic passwords and one-time public keys. However, most of them require a trusted third party (TTP) to provide services, which causes a certain degree of centralization.

[0005] In order to solve the centralization problem caused by TTP, some scholars have tried to use blockchain technology as a solution. Blockchain technology emerged in 2008 with the introduction of Bitcoin by Satoshi Nakamoto. As a revolutionary technology, blockchain is a distributed shared ledger that combines data blocks (blocks) into a specific data structure (blockchain) in a chronological and chain-like manner. Each node has a copy of the ledger.

[0006] Hena et al. proposed a three-layer authentication framework based on the Secure Remote Password Protocol (SRP), One-Time Password (OTP), and Thershold password, aiming to eliminate password guessing attacks and single point failure problems in Hadoop clusters. To this end, the authors replaced the local database of KDC with blockchain storage. However, this method of simply using blockchain technology as database storage does not maximize the use of blockchain technology, such as not deploying and running smart contracts, and the degree of decentralization is not high.

[0007] Smart contracts are programs deployed on the blockchain that can store data or execute functions. When predetermined conditions are met, certain functions will be triggered to run. Ethereum is the first platform that allows developers to design and run open smart contracts. The automatic triggering mechanism of smart contracts gives blockchain the ability to develop decentralized applications. Therefore, using blockchain smart contracts to decentralize Kerberos is an urgent problem to be solved.

[0008] The prior art discloses a security management system and method for blockchain big data, wherein the method includes the following steps: S1, establishing a big data node, applying to join the information asset network through the big data node, and uploading identity authentication data; S2, securely encrypting the identity authentication data and transaction information uploaded by the big data node; S3, performing credibility authentication on the securely encrypted identity authentication data; S4, if the authentication is passed, the big data node is determined to be a trusted big data node, and a timestamp is added to the big data blockchain; S5, securely managing the transaction information of each trusted big data node in the big data blockchain; S6, information interaction and sharing between each trusted big data node. However, the prior art does not deploy smart contracts, has a low degree of decentralization, does not perform multiple verifications and confirmations on identity information, and has low security. Summary of the invention

[0009] In order to solve the problems of low decentralization due to the failure to deploy smart contracts, lack of multiple verification and confirmation of identity information, and low security, the present invention proposes a blockchain-based security service management method and system, which improves the security of the system through the cryptographic scheme ABS key, deploys smart contracts to improve the decentralization, and repeatedly confirms the identity through authentication, tickets, and application requests to improve security.

[0010] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0011] A blockchain-based security service management method is applied to the blockchain-based security service management system, and is characterized by comprising the following steps:

[0012] S1: The participant inputs a string password to generate an AES key, and sends the ID-blockchain account address-key mapping to the key distribution center KDC; KDC encrypts the participant's AES key with its own AES key and generates an AES key encrypted by the CP-ABE encryption algorithm; the participants include user C, key distribution center KDC, and server V;

[0013] S2: KDC sends a registration request to the blockchain, sets up all participant information mapping and stores it on the blockchain, and hosts the KDC database on the blockchain;

[0014] S3: User C sends an authentication request transaction AS_REQ. The smart contract checks the identity ID and random number Nonce of the authentication request message. The KDC authentication server obtains the authentication request message from the blockchain. If the decryption is successful and the timestamp is within a certain range, the authentication request is passed.

[0015] S4: The KDC authentication server randomly generates a session key Kc, tgs, constructs an authentication ticket license, and sends an authentication response message AS_REP to the blockchain;

[0016] S5: User C sends a ticket request transaction TGS_REQ. The smart contract checks the identity ID and random number Nonce of the ticket request message. The KDC ticket server obtains TGS_REQ from the blockchain. If the decrypted ticket license is valid and the authority review is passed, the ticket request is approved.

[0017] S6: The KDC ticket server randomly generates a session key Kc,v for communication between user C and server V, constructs a service ticket ST, and sends a ticket response message TGS_REP to the blockchain;

[0018] S7: User C randomly generates a session key Ksession for communication between user C and server V, and sends an application request transaction. The smart contract checks the identity ID and random number Nonce of the application request message; server V obtains the application request message AP_REQ from the blockchain. If the decrypted message check authority passes, the application request is approved;

[0019] S8: Server V sends a service response message AP_REP to the blockchain. User C obtains the service response message AP_REP, decrypts it to obtain Ksession, and then the service session is started.

[0020] A security service management system based on blockchain, including user C, server V, and key distribution center KDC;

[0021] The key distribution center KDC includes an authentication server AS, a ticket server TGS, and a database DB;

[0022] The user C is the service applicant, and implements the security service application by sending an authentication request AS_REQ, a ticket request TGS_REQ, and an application request AP_REQ;

[0023] The server V is a service provider, which provides secure services by sending a service response AP_REP;

[0024] The key distribution center KDC provides authentication service AS_Service, ticket service TGS_Service and service security intermediary service AP_Service for user C and server V by managing participant AES keys and distributing session keys and tickets.

[0025] The system is based on AES key authentication and does not actually limit the number of exchange participants. Smart contracts are used to record the public information and associated messages of exchange participants.

[0026] The working principle of the present invention is as follows:

[0027] Through the Ethereum blockchain smart contract, multiple identity authentications are performed on participants to achieve decentralization and improve security. Cryptography solutions are added to further protect the information privacy and security of participants.

[0028] Preferably, the AES key is generated using the PBKDF2 algorithm; the PBKDF2 algorithm expression is:

[0029] DK=PBKDF2(PRF,Password,Salt,c,dkLen)

[0030] Wherein, PRF is a pseudo-random function, and the pseudo-random function is HMAC-SHA256; Password is a set of string passwords defined by user C; Salt is a set of 64-bit random strings, which is formed by artificially combining a set of random characters with the user's original password to form a new character, which is used to increase the difficulty of hash decryption; c represents the number of iterations, and the difficulty of hash decryption is increased by continuous hash iterations; dkLen represents the final output key length, which is 256 bits; DK is the final generated 256-bit AES key.

[0031] Furthermore, the calculation steps of the CP-ABE encryption algorithm include the following:

[0032] D1: Initialization, generating public parameters, system public key PK and system master key;

[0033] D2: Encryption, encrypt the message M, construct an access tree based on the access policy set by the data owner, and generate node secret values ​​for the ciphertext; only users who meet a certain number of node secret value combinations can decrypt the message M;

[0034] D3: Generate a key. Generate the private key corresponding to the user based on the user attribute set and the master private key.

[0035] D4: Decryption. The user provides the private key to decrypt and obtain the corresponding message M.

[0036] Furthermore, the verification of the random number Nonce and the timestamp in S3 uses the question-answer response mechanism;

[0037] The question-answer response mechanism includes a timestamp verification algorithm and a random number verification algorithm;

[0038] The timestamp verification algorithm is as follows: when all messages are uploaded to the chain, the timestamp of the block is taken as the timestamp of the message. When the user obtains the message, it is compared with his local time; if the time difference is within the time threshold, the message is considered valid and allowed to be uploaded to the chain; if the time difference exceeds the time threshold, the message is considered invalid;

[0039] The random number verification algorithm is as follows: When registering, each user sets a random number Nonce, which is derived by the smart contract based on the block height block.number and the block timestamp block.timestamp.

[0040] Before the user sends a message to the blockchain, the get_nonce function of the smart contract is executed to obtain a random number, and the random number Nonce is uploaded to the blockchain along with the message. During the blockchain upload process, the smart contract executes the random number check algorithm check_nonce: if the random number Nonce is the same as the random number Nonce stored corresponding to the participant's blockchain account address, the random number Nonce is automatically added by 1, and the message is successfully uploaded to the blockchain; if they are different, it means that the random number Nonce is wrong and is not allowed to be uploaded to the blockchain.

[0041] Furthermore, the smart contract includes a user structure User and a message structure Packet;

[0042] The user structure User includes an identity ID as a string variable, a blockchain account address Address, an AES key, a permission list Permission List, a valid time Life Time, a login status is_login as a boolean variable, a random number nonce as a uint256 variable, a user registration timestamp timestamp, and multiple mappings mapping (string=>Packet) to bind string type messages AS-REQ, AS-REP, TGS-REQ, TGS-REP, AP-REQ, AP-REP to the message sender;

[0043] The message structure Packet includes content content as a string variable and timestamp timestamp of the message as a uint256 variable.

[0044] Furthermore, the message structure Packet is bound to the identity ID through multiple mappings mapping(string=>Packet);

[0045] Through setup, get_nonce, check_nonce, AS_EX, TGS_EX, and AP_EX, the initialization of smart contract storage content, replay attack defense, and message access are completed.

[0046] Furthermore, the participant information mapping includes identity ID, blockchain account address Address, AES key, permission list Permission List, and validity time Life Time;

[0047] The format of the identity ID is: "user nickname@domain name", and the permission list is also encrypted by the KDC key; the permission list is a list of services that the user can access, and it is stipulated that after the validity period, the user will automatically go offline; all user information is stored in the user structure User of the smart contract.

[0048] More specifically, the propagation direction of AS_REQ is from C to AS, and the content is: {IDc, IDtgs, Nonce, Kc{TimeStamp}};

[0049] The transmission direction of AS-REP is from AS to C, and the content is: Kc{Kc, tgs, IDc, IDtgs, Nonce, TimeStamp,, TGT}, TGT = Ktgs{IDc, IDtgs, Kc, tgs, lifetime};

[0050] The transmission direction of TGS-REQ is from C to TGS, and the content is: IDc, IDv, TimeStamp, Nonce, TGT, Authenticator1; Authenticator1 = Kc, tgs{IDc, CheckSum, TimeStamp};

[0051] The transmission direction of TGS-REP is from TGS to C, and the content is: Kc, tgs{Kc, v, IDc, IDv, ST, Nonce, TimeStamp};

[0052] The transmission direction of AP-REQ is from C to S, and the content is: IDc, IDv, TimeStamp, ST, Authenticator2; Authenticator2 = Kc, v{IDc, CheckSum, Ksession, TimeStamp};

[0053] The transmission direction of AP-REP is from S to C, and the content is Kc, v{IDc, IDv, TimeStamp};

[0054] Kx{} represents encryption with the key of this subscript. In all tags, the subscripts kdc and tgs represent the same entity; Kc represents the user key, which is used to encrypt the AS-REQ timestamp and AS-REP message; Ktgs: represents the KDC key, which is used to encrypt TGT; Kv represents the server key, which is used to encrypt ST; Kc, tgs represents the session key between the client and KDC, which is used to encrypt Authenticator1 in the TGS-REQ message; Kc, v represents the session key between the client and the server, which is used to encrypt Authenticator2 in the AP-REQ message; Ksession represents the temporary session key between the client and the server, which is used to encrypt the service session between the client and the server; the key types of Kc, Ktgs, Kv, Kc, Kc, v, and Ksession are all AES-256.

[0055] More specifically, the ABE key includes the system public key PK, the system master private key MSK, and the KDC private key SK;

[0056] The system public key PK is used to encrypt the KDC AES key;

[0057] The system master private key MSK is used to decrypt the KDC AES key;

[0058] The KDC private key SK is used to decrypt the KDC AES key.

[0059] Compared with the prior art, the present invention has the following beneficial effects:

[0060] 1. The cryptographic scheme CP-ABE has been added to achieve on-chain data privacy, protect user private keys, and protect user information security and privacy security.

[0061] 2. Smart contracts are deployed to achieve decentralization, and multiple verifications and confirmations are performed on identity information to improve security.

[0062] 3. Since traditional Kerberos does not provide authorization services, the present invention simplifies the authorization process to participants reading the Permission List to confirm permissions. Compared with traditional security service management, the present invention adds features such as decentralization, traceability, privacy protection and transparency, and implements the 3AS principle, that is, providing three major functions: access control, authorization and auditing. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 This is a flow chart of a blockchain-based security service management method according to the present invention.

[0064] Figure 2 This is a schematic diagram of the structure of a blockchain-based security service management system described in the present invention.

[0065] Figure 3 Schematic diagram of the question-answer response mechanism described in the embodiment.

[0066] Figure 4 Schematic diagram of the decentralized authentication and authorization mechanism described in the embodiment. DETAILED DESCRIPTION

[0067] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments.

[0068] Example 1

[0069] A blockchain-based security service management method, such as Figure 1 As shown, the method is applied to a blockchain-based security service management system, which is characterized by comprising the following steps:

[0070] S1: The participant inputs a string password to generate an AES key, and sends the ID-blockchain account address-key mapping to the key distribution center KDC; KDC encrypts the participant's AES key with its own AES key and generates an AES key encrypted by the CP-ABE encryption algorithm; the participants include user C, key distribution center KDC, and server V;

[0071] S2: KDC sends a registration request to the blockchain, sets up all participant information mapping and stores it on the blockchain, and hosts the KDC database on the blockchain;

[0072] S3: User C sends an authentication request transaction AS_REQ. The smart contract checks the identity ID and random number Nonce of the authentication request message. The KDC authentication server obtains the authentication request message from the blockchain. If the decryption is successful and the timestamp is within a certain range, the authentication request is passed.

[0073] S4: The KDC authentication server randomly generates a session key Kc, tgs, constructs an authentication ticket license, and sends an authentication response message AS_REP to the blockchain;

[0074] S5: User C sends a ticket request transaction TGS_REQ. The smart contract checks the identity ID and random number Nonce of the ticket request message. The KDC ticket server obtains TGS_REQ from the blockchain. If the decrypted ticket license is valid and the authority review is passed, the ticket request is approved.

[0075] S6: The KDC ticket server randomly generates a session key Kc,v for communication between user C and server V, constructs a service ticket ST, and sends a ticket response message TGS_REP to the blockchain;

[0076] S7: User C randomly generates a session key Ksession for communication between user C and server V, and sends an application request transaction. The smart contract checks the identity ID and random number Nonce of the application request message; server V obtains the application request message AP_REQ from the blockchain. If the decrypted message check authority passes, the application request is approved;

[0077] S8: Server V sends a service response message AP_REP to the blockchain. User C obtains the service response message AP_REP, decrypts it to obtain Ksession, and then the service session is started.

[0078] A blockchain-based security service management system, such as Figure 2 As shown, it includes user C, server V, key distribution center KDC, smart contract, and blockchain;

[0079] The key distribution center KDC includes an authentication server AS, a ticket server TGS, and a database DB;

[0080] The user C is the service applicant, and implements the security service application by sending an authentication request AS_REQ, a ticket request TGS_REQ, and an application request AP_REQ;

[0081] The server V is a service provider, which provides secure services by sending a service response AP_REP;

[0082] The key distribution center KDC provides authentication transactions, ticket transactions, and application transactions for user C and server V by managing participant AES keys and distributing session keys and tickets.

[0083] The working principle of the present invention is as follows:

[0084] Through the Ethereum blockchain smart contract, multiple identity authentications are performed on participants to achieve decentralization and improve security. Cryptography solutions are added to further protect the information privacy and security of participants.

[0085] In this embodiment, the AES key is generated using the PBKDF2 algorithm; the PBKDF2 algorithm is an algorithm that derives a key based on a passphrase and a salt, and a hash;

[0086] The PBKDF2 algorithm expression is:

[0087] DK=PBKDF2(PRF,Password,Salt,c,dkLen)

[0088] Wherein, PRF is a pseudo-random function, which can be understood as a hash function, and the pseudo-random function is HMAC-SHA256; Password is a string password defined by a user C; Salt is a set of 64-bit random strings, which is formed by artificially combining a set of random characters with the user's original password to form a new character, which is used to increase the difficulty of hash decryption; c represents the number of iterations, and the difficulty of hash decryption is increased by continuous hash iterations; dkLen represents the final output key length, which is 256 bits; DK is the final generated 256-bit AES key.

[0089] The initial password and salt are processed through the PRF to generate the initial key, and then the initial key is used as the next input and password to be processed through the PRF again to generate the subsequent key. This is repeated until the number of iterations defined above is reached. The generated key is then XORed to generate the final AES key.

[0090] Example 2

[0091] In this embodiment, the calculation steps of the CP-ABE encryption algorithm include the following:

[0092] D1: Initialization, generating public parameters, system public key PK and system master key;

[0093] D2: Encryption, encrypt the message M, construct an access tree based on the access policy set by the data owner, and generate node secret values ​​for the ciphertext; only users who meet a certain number of node secret value combinations can decrypt the message M;

[0094] D3: Generate a key. Generate the private key corresponding to the user based on the user attribute set and the master private key.

[0095] D4: Decryption. The user provides the private key to decrypt and obtain the corresponding message M.

[0096] The verification of random number Nonce and timestamp in S3 uses the question-answer response mechanism;

[0097] More specifically, the question-answer response mechanism includes a timestamp verification algorithm and a random number verification algorithm;

[0098] The timestamp verification algorithm is as follows: when all messages are uploaded to the chain, the timestamp of the block is taken as the timestamp of the message. When the user obtains the message, it is compared with his local time; if the time difference is within the time threshold, the message is considered valid and allowed to be uploaded to the chain; if the time difference exceeds the time threshold, the message is considered invalid;

[0099] The random number verification algorithm is as follows: When registering, each user sets a random number Nonce, which is derived by the smart contract based on the block height block.number and the block timestamp block.timestamp.

[0100] Before the user sends a message to the blockchain, the get_nonce function of the smart contract is executed to obtain a random number, and the random number Nonce is uploaded to the blockchain along with the message. During the blockchain upload process, the smart contract executes the random number check algorithm check_nonce: if the random number Nonce is the same as the random number Nonce stored corresponding to the participant's blockchain account address, the random number Nonce is automatically added by 1, and the message is successfully uploaded to the blockchain; if they are different, it means that the random number Nonce is wrong and is not allowed to be uploaded to the blockchain.

[0101] Example 3

[0102] In this embodiment, the smart contract includes a user structure User and a message structure Packet;

[0103] The user structure User includes an identity ID as a string variable, a blockchain account address Address, an AES key, a permission list Permission List, a valid time Life Time, a login status is_login as a boolean variable, a random number nonce as a uint256 variable, a user registration timestamp timestamp, and multiple mappings mapping (string=>Packet) to bind string type messages AS-REQ, AS-REP, TGS-REQ, TGS-REP, AP-REQ, AP-REP to the message sender;

[0104] The message structure Packet includes content content as a string variable and timestamp timestamp of the message as a uint256 variable.

[0105] More specifically, the message structure Packet is bound to the identity ID through multiple mappings mapping(string=>Packet);

[0106] Through setup, get_nonce, check_nonce, AS_EX, TGS_EX, and AP_EX, the initialization of smart contract storage content, replay attack defense, and message access are completed.

[0107] In this embodiment, if Figure 4 As shown, the decentralized authentication and authorization mechanism is as follows:

[0108] Through smart contracts, user identification and blockchain account address are bound. Each transaction sent by the user through a decentralized application can prove the identity of the user. Authentication transactions are set up, including the access to authentication request AS-REQ and authentication response AS-REP messages; ticket transactions are set up, including the access to ticket request TGS-REQ and ticket response TGS-REP messages, which are used to obtain access credentials ST for accessing specific server services; application transactions are set up, including the access to application request AP-REQ and application response AP-REP messages, which are used to implement secure service sessions.

[0109] The participant information mapping includes identity ID, blockchain account address Address, AES key, permission list Permission List, and validity period Life Time;

[0110] The format of the identity ID is: "user nickname@domain name", and the permission list is also encrypted by the KDC key; the permission list is a list of services that the user can access, and it is stipulated that after the validity period, the user will automatically go offline; all user information is stored in the user structure User of the smart contract.

[0111] More specifically, the propagation direction of AS_REQ is from C to AS, and the content is: {IDc, IDtgs, Nonce, Kc{TimeStamp}};

[0112] The transmission direction of AS-REP is from AS to C, and the content is: Kc{Kc, tgs, IDc, IDtgs, Nonce, TimeStamp,, TGT}, TGT = Ktgs{IDc, IDtgs, Kc, tgs, lifetime};

[0113] The transmission direction of TGS-REQ is from C to TGS, and the content is: IDc, IDv, TimeStamp, Nonce, TGT, Authenticator1; Authenticator1 = Kc, tgs{IDc, CheckSum, TimeStamp};

[0114] The transmission direction of TGS-REP is from TGS to C, and the content is: Kc, tgs{Kc, v, IDc, IDv, ST, Nonce, TimeStamp};

[0115] The transmission direction of AP-REQ is from C to S, and the content is: IDc, IDv, TimeStamp, ST, Authenticator2; Authenticator2 = Kc, v{IDc, CheckSum, Ksession, TimeStamp};

[0116] The transmission direction of AP-REP is from S to C, and the content is Kc, v{IDc, IDv, TimeStamp};

[0117] Kx{} represents encryption with the key of this subscript. In all tags, the subscripts kdc and tgs represent the same entity; Kc represents the user key, which is used to encrypt the AS-REQ timestamp and AS-REP message; Ktgs: represents the KDC key, which is used to encrypt TGT; Kv represents the server key, which is used to encrypt ST; Kc, tgs represents the session key between the client and KDC, which is used to encrypt Authenticator1 in the TGS-REQ message; Kc, v represents the session key between the client and the server, which is used to encrypt Authenticator2 in the AP-REQ message; Ksession represents the temporary session key between the client and the server, which is used to encrypt the service session between the client and the server; the key types of Kc, Ktgs, Kv, Kc, Kc, v, and Ksession are all AES-256.

[0118] More specifically, the ABE key includes the system public key PK, the system master private key MSK, and the KDC private key SK;

[0119] The system public key PK is used to encrypt the KDC AES key;

[0120] The system master private key MSK is used to decrypt the KDC AES key;

[0121] The KDC private key SK is used to decrypt the KDC AES key.

[0122] Obviously, the above embodiments of the present invention are only examples for clearly explaining the present invention, and are not intended to limit the implementation methods of the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention shall be included in the protection scope of the claims of the present invention.

Claims

1. A security service management method based on blockchain, characterized in that: The following steps are involved: S1: The participant inputs a string password to generate an AES key, and sends the ID-blockchain account address-key mapping to the key distribution center KDC; KDC encrypts the participant's AES key with its own AES key and generates an AES key encrypted by the CP-ABE encryption algorithm; the participants include user C, key distribution center KDC, and server V; S2: KDC sends a registration request to the blockchain, sets up all participant information mapping and stores it on the blockchain, and hosts the KDC database on the blockchain; S3: User C sends an authentication request transaction AS_REQ. The smart contract checks the identity ID and random number Nonce of the authentication request message. The KDC authentication server obtains the authentication request message from the blockchain. If the decryption is successful and the timestamp is within a certain range, the authentication request is passed. S4: The KDC authentication server randomly generates a session key Kc, tgs, constructs an authentication ticket license, and sends an authentication response message AS_REP to the blockchain; S5: User C sends a ticket request transaction TGS_REQ. The smart contract checks the identity ID and random number Nonce of the ticket request message. The KDC ticket server obtains TGS_REQ from the blockchain. If the decrypted ticket license is valid and the authority review is passed, the ticket request is approved. S6: The KDC ticket server randomly generates a session key Kc,v for communication between user C and server V, constructs a service ticket ST, and sends a ticket response message TGS_REP to the blockchain; S7: User C randomly generates a session key Ksession for communication between user C and server V, and sends an application request transaction. The smart contract checks the identity ID and random number Nonce of the application request message; server V obtains the application request message AP_REQ from the blockchain. If the decrypted message check authority passes, the application request is approved; S8: Server V sends a service response message AP_REP to the blockchain. User C obtains the service response message AP_REP, decrypts it to obtain Ksession, and then the service session is started.

2. According to claim 1, a blockchain-based security service management method is characterized in that: The AES key is generated using the PBKDF2 algorithm; the PBKDF2 algorithm expression is: DK=PBKDF2(PRF,Password,Salt,c,dkLen) Wherein, PRF is a pseudo-random function, and the pseudo-random function is HMAC-SHA256; Password is a set of string passwords defined by user C; Salt is a set of 64-bit random strings, which is formed by artificially combining a set of random characters with the user's original password to form a new character, which is used to increase the difficulty of hash decryption; c represents the number of iterations, and the difficulty of hash decryption is increased by continuous hash iterations; dkLen represents the final output key length, which is 256 bits; DK is the final generated 256-bit AES key.

3. According to a blockchain-based security service management method according to claim 1, it is characterized in that: The calculation steps of the CP-ABE encryption algorithm include the following: D1: Initialization, generating public parameters, system public key PK and system master key; D2: Encryption, encrypt the message M, construct an access tree based on the access policy set by the data owner, and generate node secret values ​​for the ciphertext; only users who meet a certain number of node secret value combinations can decrypt the message M; D3: Generate a key. Generate the private key corresponding to the user based on the user attribute set and the master private key. D4: Decryption. The user provides the private key to decrypt and obtain the corresponding message M.

4. A blockchain-based security service management method according to claim 1, characterized in that: The verification of random number Nonce and timestamp in S3 uses the question-answer response mechanism; The question-answer response mechanism includes a timestamp verification algorithm and a random number verification algorithm; The timestamp verification algorithm is as follows: when all messages are uploaded to the chain, the timestamp of the block is taken as the timestamp of the message. When the user obtains the message, it is compared with his local time; if the time difference is within the time threshold, the message is considered valid and allowed to be uploaded to the chain; if the time difference exceeds the time threshold, the message is considered invalid; The random number verification algorithm is as follows: when registering, each user sets a random number Nonce, which is derived by the smart contract based on the block height block.number and the block timestamp block.timestamp; Before the user sends a message to the blockchain, the get_nonce function of the smart contract is executed to obtain a random number, and the random number Nonce is uploaded to the blockchain along with the message. During the blockchain upload process, the smart contract executes the random number check algorithm check_nonce: if the random number Nonce is the same as the random number Nonce stored corresponding to the participant's blockchain account address, the random number Nonce is automatically added by 1, and the message is successfully uploaded to the blockchain; if they are different, it means that the random number Nonce is wrong and is not allowed to be uploaded to the blockchain.

5. A blockchain-based security service management method according to claim 1, characterized in that: The smart contract includes a user structure User and a message structure Packet; The user structure User includes an identity ID as a string variable, a blockchain account address Address, an AES key, a permission list Permission List, a valid time Life Time, a login status is_login as a boolean variable, a random number Nonce as a uint256 variable, a user registration timestamp timestamp, and multiple mappings mapping (string=>Packet) to bind string type messages AS-REQ, AS-REP, TGS-REQ, TGS-REP, AP-REQ, AP-REP to the message sender; The message structure Packet includes content content as a string variable and timestamp timestamp of the message as a uint256 variable.

6. A blockchain-based security service management method according to claim 5, characterized in that: Bind the message structure Packet to the identity ID through multiple mappings mapping(string=>Packet); Through setup, get_nonce, check_nonce, AS_EX, TGS_EX, and AP_EX, the initialization of smart contract storage content, replay attack defense, and message access are completed.

7. A blockchain-based security service management method according to claim 6, characterized in that: The participant information mapping includes identity ID, blockchain account address Address, AES key, permission list PermissionList, and validity time Life Time; The format of the identity ID is: "user nickname@domain name", and the permission list is also encrypted by the KDC key; the permission list is a list of services that the user can access, and it is stipulated that after the validity period, the user will automatically go offline; all user information is stored in the user structure User of the smart contract.

8. A blockchain-based security service management method according to claim 7, characterized in that: The transmission direction of AS_REQ is from C to AS, and its content is: {IDc, IDtgs, Nonce, Kc{TimeStamp}}; The transmission direction of AS-REP is from AS to C, and the content is: Kc{Kc, tgs, IDc, IDtgs, Nonce, TimeStamp,, TGT}, TGT = Ktgs{IDc, IDtgs, Kc, tgs, lifetime}; The transmission direction of TGS-REQ is from C to TGS, and the content is: IDc, IDv, TimeStamp, Nonce, TGT, Authenticator1; Authenticator1 = Kc, tgs{IDc, CheckSum, TimeStamp}; The transmission direction of TGS-REP is from TGS to C, and the content is: Kc, tgs{Kc, v, IDc, IDv, ST, Nonce, TimeStamp}; The transmission direction of AP-REQ is from C to S, and the content is: IDc, IDv, TimeStamp, ST, Authenticator2; Authenticator2 = Kc, v{IDc, CheckSum, Ksession, TimeStamp}; The transmission direction of AP-REP is from S to C, and the content is Kc, v{IDc, IDv, TimeStamp}; Kx{} represents encryption with the key of this subscript. In all tags, the subscripts kdc and tgs represent the same entity; Kc represents the user key, which is used to encrypt the AS-REQ timestamp and AS-REP message; Ktgs: represents the KDC key, which is used to encrypt TGT; Kv represents the server key, which is used to encrypt ST; Kc, tgs represents the session key between the client and KDC, which is used to encrypt Authenticator1 in the TGS-REQ message; Kc, v represents the session key between the client and the server, which is used to encrypt Authenticator2 in the AP-REQ message; Ksession represents the temporary session key between the client and the server, which is used to encrypt the service session between the client and the server; the key types of Kc, Ktgs, Kv, Kc, Kc, v, and Ksession are all AES-256.

9. A blockchain-based security service management method according to claim 1, characterized in that: ABE keys include system public key PK, system master private key MSK, and KDC private key SK; The system public key PK is used to encrypt the KDC AES key; The system master private key MSK is used to decrypt the KDC AES key; The KDC private key SK is used to decrypt the KDC AES key.

10. A blockchain-based security service management system, applied to a blockchain-based security service management method as claimed in claim 1, characterized in that: Including user C, server V, key distribution center KDC, smart contract, and blockchain; The key distribution center KDC includes an authentication server AS, a ticket server TGS, and a database DB; The user C is the service applicant, and implements the security service application by sending an authentication request AS_REQ, a ticket request TGS_REQ, and an application request AP_REQ; The server V is a service provider, which provides secure services by sending a service response AP_REP; The key distribution center KDC provides authentication transactions, ticket transactions, and application transactions for user C and server V by managing participant AES keys and distributing session keys and tickets.

Images