A single sign-on transparentization method and system supporting ticket privacy protection

Abstract

The application discloses a single sign-on transparentization method and system supporting bill privacy protection and relates to the technical field of data security. The system comprises a distributed key generation committee which generates a main public key of an identity-based encryption framework in a single sign-on system and broadcasts in the single sign-on system; each member in the distributed key generation committee calculates a main private key share of the identity-based encryption framework, carries out user identity registration based on the main public key and the main private key share, submits bill ciphertext to a log server when the user accesses a service provider, and obtains a signed bill timestamp issued by the log server; the service provider verifies the correctness of the bill ciphertext, the signed bill timestamp and a binding proof; after verification, the user decrypts the bill ciphertext and checks whether the bill is the bill used by the user. The application has better privacy protection effect.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a method and system for making single sign-on transparent and supporting ticket privacy protection. Background Technology

[0002] Single Sign-On (SSO) is an identity management method proposed to address the increasingly complex network environment. It allows users to use identity credentials (tickets) issued by a single entity to complete authentication across multiple service providers (SPs) that trust that entity, which is called the Identity Provider (IdP). SSO is mainly used to meet user authentication and authorization needs. Mainstream SSO protocols include OAuth 2.0, SAML, and OpenConnect ID. Different protocols can be selected for different application scenarios to adapt to the needs of the scenario. Currently, SSO technology has been widely used in cloud computing, the Internet of Things, and even some banking institutions (openbanking) have introduced this technology. The application scenarios of SSO in information systems mainly include: (1) SSO within a single system, allowing users to log in to multiple applications or access multiple resources with a one-time user authentication without having to log in repeatedly; (2) Federated Identity Management (FIM) between multiple systems, allowing multiple applications from different vendors to share, manage, and authenticate user identities. For example, FIM allows users of a certain enterprise to log in to one application and then access several other enterprise applications without having to log in again. Similarly, some well-known companies (such as Google, Facebook, PayPal, etc.) provide single sign-on services to users as IdPs, allowing users to log in to numerous applications using their IdP account identity.

[0003] In a single sign-on (SSO) system, because the user identity credentials (tokens / tickets) provided by an IdP can be trusted and accepted by multiple Service Providers (SPs), users only need to register their identity with the IdP to access the corresponding SP, avoiding redundant identity registration and simplifying the user identity management process. Similar to Public Key Infrastructure (PKI) systems, SSO systems reduce the overhead of identity management for both users and SPs by introducing IdPs as trust anchors. However, using IdPs as trust anchors in SSO systems also faces the single point of failure problem encountered in PKI systems, which rely on Certificate Authorities (CAs). Many recognized CAs have been compromised or fraudulently issued with fake certificates. Compared to CAs, IdPs issue tokens more frequently and interact directly with users; therefore, IdPs are arguably more vulnerable to attacks and single point of failure than CAs. Evidence already exists regarding a range of attack methods for generating fake tokens. Some attacks stemmed from network issues, such as vulnerabilities CVE-2022-39339 and CVE-2021-27582. Others were caused by deployment problems, such as the vulnerability CVE-2023-22482. In the SolarWinds security incident, hackers exploited the Golden SAML (using a stolen key to forge a signed SAML response for unauthorized access) attack method to compromise their Orion network monitoring software, resulting in a large-scale network attack and the leakage of important data. However, in existing single sign-on systems, due to the centralized trust in Identity Owners (IdOs), users cannot intervene in any improper actions by the IdO (e.g., incorrectly issuing tokens due to malicious intent or attacks). Other participants in the system also cannot identify improper actions by the IdO. Once a fake token appears, it can have a widespread impact within the system and is difficult to trace. Single sign-on systems are now widely deployed worldwide, and the losses caused by fake tokens are correspondingly increasing. Therefore, taking measures to audit improper IdP behavior is an urgent problem to be solved in building a secure single sign-on infrastructure.

[0004] Digital forensics aims to gain a deeper understanding of an event or object by collecting and analyzing facts related to it. A Forensic Investigated Team (FIT) reconstructs the truth of an event by investigating, collecting, and presenting the actions of the investigated party within digital systems.

[0005] The digital forensics process comprises four steps: identifying evidence, collecting evidence, organizing evidence, and presenting evidence. In digital systems, the user login process typically involves information such as user identity, login time, IP address, and device information—information that can be used to track user activity. This information can be used to reconstruct timelines, track user misconduct, and serve as legal evidence when necessary. Digital forensics of this information can, to some extent, demonstrate the facts of cybercrime and link suspects to criminal activities, making it a crucial step in digital forensics investigations. However, digital forensics faces challenges such as difficulty in evidence collection and poor admissibility due to the dispersed nature of user login activities, service providers' privacy protection of user login information, and the potential for service providers to collude with users to compromise the integrity of evidence, rendering it unusable. Single sign-on (SSO) systems, compared to traditional digital systems, use a unified login token generated by an identity provider, which to some extent solves the problem of difficulty in evidence collection caused by the dispersed nature of user login activities. However, how to protect user login privacy while ensuring the integrity of the collected evidence remains a pressing issue. Summary of the Invention

[0006] The purpose of this invention is to provide a single sign-on transparency method and system that supports ticket privacy protection, and has a better privacy protection effect.

[0007] To achieve the above objectives, the present invention provides the following solution:

[0008] A method for achieving transparent single sign-on that supports ticket privacy protection includes:

[0009] The distributed key generation committee generates the master public key of the identity-based encryption framework within the single sign-on system and broadcasts it within the single sign-on system; each member of the distributed key generation committee calculates the share of the master private key of the identity-based encryption framework.

[0010] Users register their identity with an identity provider and obtain a user identity identifier generated by the identity provider. The user then sends this user identity identifier to the distributed key generation committee. The distributed key generation committee selects t members to form a first set, and generates a user private key share bound to the user's identity identifier based on the master private key share corresponding to each member in the first set. After receiving the user private key share bound to the user identity identifier, the user calculates their private key using each user private key share and verifies the correctness of the user private key using the master public key; t is a threshold value.

[0011] When a user accesses a service provider, the identity provider issues a ticket to the user and generates a binding certificate that links the ticket to the user's identity identifier. The identity provider encrypts the ticket using the user's identity identifier and master public key contained in the ticket, generates ticket ciphertext, submits the ticket ciphertext to a log server, and obtains a signed ticket timestamp issued by the log server. The identity provider then sends verification information to the service provider, which includes the ticket, the binding certificate, the ticket ciphertext, and the signed ticket timestamp.

[0012] After receiving the verification information, the service provider verifies the correctness of the verification information. The conditions for the verification information to be correct are that the ticket was issued by the identity provider, the timestamp of the signed ticket was signed by the log server, and the binding proof proves that the encrypted ticket is decryptable for the user to whom the encrypted ticket belongs.

[0013] Once the verification information is verified to be correct, the service provider successfully authenticates the user's identity and provides services to the user.

[0014] When a user has an auditing requirement, the user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's user identity in the log server. If the decryption is successful, the decrypted ticket is audited.

[0015] Optionally, the distributed key generation committee generates the master public key for the identity-based cryptographic framework within the single sign-on system in a distributed manner, and broadcasts it within the single sign-on system, specifically including:

[0016] Each member of the distributed key generation committee selects a secret value and shares it among themselves using a threshold secret sharing method. At the same time, they calculate the share of the master public key based on the secret value and broadcast it within the single sign-on system. After all the secret values ​​selected by the members of the distributed key generation committee have been shared, each member calculates their share of the master private key based on the received share of the threshold secret shared secret value.

[0017] Once all members of the distributed key generation committee have broadcast their calculated public key shares, each member in the single sign-on system calculates their public key based on the received public key shares.

[0018] Optionally, when a member of the distributed key generation committee is revoked, if the distributed key generation committee does not meet the security assumptions after the member is revoked, the single sign-on protocol is terminated; the security assumptions are that the sum of the number of malicious members and the number of revoked members in the distributed key generation committee is less than a threshold, and the number of members executing the single sign-on protocol is greater than or equal to the threshold.

[0019] When a member is revoked and a new member applies to join the distributed key generation committee, the new member submits a membership application to the distributed key generation committee, and each member of the distributed key generation committee sends the secret value share of the revoked member to the new member.

[0020] When a new member receives t secret value shares, the secret value used by the current revoked member to calculate the master private key is obtained by interpolation based on the t secret value shares. The new member then uses the secret value used by the current revoked member to calculate the master private key as its own secret value.

[0021] Optionally, the formula for calculating a user's private key using each user's private key share is expressed as follows:

[0022]

[0023] Where sk(ID) represents the user's private key, ID represents the user's identity identifier, S represents the first set, and the number of members in S is greater than a threshold, c i This represents the member number of the i-th member in the first set within the distributed key generation committee. This indicates that the i-th member in the first set uses The calculated share of the user's private key. This represents the share of the master private key of the i-th member in the first set.

[0024] Optionally, verifying the correctness of the user's private key using the master public key specifically includes:

[0025] Verify the equation Is it valid?

[0026] If so, then the user's private key is correct;

[0027] If not, the user's private key is incorrect, and the user shall issue a report of malicious behavior by the distributed key generation committee.

[0028] in, This represents a bilinear mapping, where sk(ID) represents the user's private key, ID represents the user's identity identifier, and g represents... In the middle generator, express The second input group, Let h = g represent the first hash function. sk sk represents the master private key.

[0029] Optionally, the binding proof is represented as:

[0030] Where bp represents the binding proof, This represents the first hash function, ID represents the user identifier, and r represents... Random numbers in the data;

[0031] The encrypted representation of the bill is as follows:

[0032] Where ε(token) represents the encrypted document, u represents the first component of the encrypted document, v represents the second component of the encrypted document, and h = g sk sk represents the master private key, g represents... In the middle generator, express The second input group, Let represent the set of all elements in the residue class modulo q that are relatively prime to q, where q is a large prime number. Represents a bilinear mapping. This represents the second hash function.

[0033] Optionally, the user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's identity in the log server, which is represented as:

[0034]

[0035] Wherein, Token represents the decryption result of the encrypted document. This represents the second hash function. This represents a bilinear mapping, where sk(ID) represents the user's private key, ID represents the user's identity identifier, u represents the first component of the ciphertext of the ticket, and v represents the second component of the ciphertext of the ticket.

[0036] Optionally, a single sign-on transparency method supporting ticket privacy protection further includes: after the verification information is verified as correct, when the user has an auditing requirement, the user uses the user's private key to decrypt the ticket ciphertext corresponding to the user's user identity in the log server. If the decryption is successful, the decrypted ticket is audited, specifically including:

[0037] If decryption is successful, it is determined whether the decrypted ticket matches the ticket in the user's login information. If an inconsistency is detected, it is reported that the identity provider has engaged in malicious behavior of forging user tickets.

[0038] Optionally, a method for achieving transparent single sign-on that supports ticket privacy protection also includes:

[0039] The digital forensics investigation team sends an authorization application to the judicial authorities to conduct an investigation on the target user. The authorization includes the user's identity identifier and the scope of the investigation requested by the digital forensics investigation team.

[0040] After receiving the authorization application, the judicial authorities will send the authorization content of the investigation to the digital evidence investigation team;

[0041] The digital forensics investigation team sends the received authorization content to the distributed key generation committee;

[0042] After receiving the authorization message, the distributed key generation committee extracts the ciphertext of the ticket that falls within the scope of the application investigation from the log server. For each ciphertext of the ticket that falls within the scope of the application investigation, it selects t members to form a second set. Each member in the second set generates the decryption share of the target user based on their own master private key share and the first component of the ciphertext of the ticket. The ciphertext of the ticket that falls within the scope of the application investigation and each of the decryption shares are sent to the digital forensics investigation team.

[0043] For each encrypted document received that falls within the scope of the investigation application, when the digital forensics investigation team receives t decryption shares for a single encrypted document, it decrypts the document based on the encrypted document and the corresponding t decryption shares; thus obtaining each decrypted document corresponding to the target user's user identity.

[0044] This invention also discloses a single sign-on transparency system that supports ticket privacy protection, comprising: a distributed key generation committee, users, identity providers, and service providers;

[0045] The distributed key generation committee is used to generate the master public key of the identity-based encryption framework within the single sign-on system in a distributed manner, and broadcast it within the single sign-on system; each member of the distributed key generation committee calculates the master private key share of the identity-based encryption framework.

[0046] The user registers their identity with an identity provider, obtains a user identity identifier generated by the identity provider, and sends the user identity identifier to the distributed key generation committee. The distributed key generation committee selects t members to form a first set, and generates a user private key share bound to the user's identity identifier based on the master private key share corresponding to each member in the first set. After receiving the user private key share bound to the user identity identifier, the user calculates the user private key using each user private key share, and verifies the correctness of the user private key using the master public key.

[0047] When a user accesses a service provider, the identity provider issues a ticket to the user and generates a binding certificate that links the ticket to the user's identity identifier. The identity provider encrypts the ticket using the user's identity identifier and master public key contained in the ticket to generate ciphertext, submits the ciphertext to a log server, and obtains a signed ticket timestamp issued by the log server. The identity provider then sends verification information to the service provider, which includes the ticket, the binding certificate, the ciphertext, and the signed ticket timestamp.

[0048] The service provider is used to verify the correctness of the verification information after receiving it. The conditions for the verification information to be correct are that the ticket is issued by the identity provider, the timestamp of the signed ticket is signed by the log server, and the binding proof is used to prove that the encrypted ticket is decryptable for the user to whom the encrypted ticket belongs.

[0049] Once the verification information is verified to be correct, the service provider successfully authenticates the user's identity and provides services to the user.

[0050] When a user has an auditing requirement, the user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's user identity in the log server. If the decryption is successful, the decrypted ticket is audited.

[0051] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0052] This invention achieves oversight of service provider behavior by utilizing a log server to record tokens, with users acting as monitors to audit, thus avoiding centralized trust. Secondly, the Identity Based Encryption (IBE) framework is established in a distributed manner by Distributed Public Key Generators (DPKGs), avoiding centralized reliance on a single entity while providing privacy protection for publicly recorded tokens. Finally, the log server is audited by the service provider to ensure the integrity of log records, that the ciphertext corresponding to accepted tokens is recorded in the correct log server fragments, and that it can be decrypted by the user recorded in the token, achieving transparent single sign-on with privacy protection. This invention is also applicable to federated identity systems with single sign-on as a system component. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 A schematic diagram of a single sign-on transparency method supporting ticket privacy protection provided by an embodiment of the present invention;

[0055] Figure 2 This is a schematic diagram illustrating the complete process of a single sign-on transparency method that supports ticket privacy protection, provided by an embodiment of the present invention.

[0056] Figure 3 This is a schematic diagram of the user registration process provided in an embodiment of the present invention;

[0057] Figure 4 This is a schematic diagram of the bill issuance stage process provided in an embodiment of the present invention;

[0058] Figure 5 This is a schematic diagram of the bill monitoring stage process provided in an embodiment of the present invention;

[0059] Figure 6 This is a schematic diagram of the digital evidence collection stage process provided in an embodiment of the present invention. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] The purpose of this invention is to provide a transparent single sign-on method and system that supports ticket privacy protection, and has a better privacy protection effect.

[0062] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0063] This invention combines Identity-Based Encryption (IBE) technology with distributed key generation technology. A distributed IBE framework is established by a Distributed Public Key Generator (DPKG) to securely record tokens issued by IdPs in a single sign-on system to a log server. This ensures that users can audit entries to identify improper actions such as incorrect token issuance by IdPs. Furthermore, the completeness of the entries in the log server also serves as forensic evidence in investigations of users' cybercriminal activities.

[0064] Since the Token contains a large amount of user privacy information, the secure recording is manifested as follows: (1) Attackers outside the system (single sign-on system) cannot obtain the plaintext information of the user's Token and the connection between different entries in the log server based on the public information leaked during the operation of the system; (2) Members within the system cannot obtain the privacy information that they should not have in the protocol, except for the knowledge they originally possess. Specifically, the IdP possesses all information within the system; the user only possesses the Token information associated with their own identity; the SP only possesses the Token information sent to them by the IdP; the FIT only possesses the Token information within its scope of authority; and the DPKG members and the log server do not possess privacy information.

[0065] This invention comprises six participants: DPKG, users (who also act as log server monitors), SPs (who also act as log server auditors), IdPs, the Log Server, and FITs. The DPKG is a set of entities that generate the IBE public key for the entire system and corresponding IBE private keys for each user, each bound to their identity. The characteristics of this entity set are denoted by (n,t), where n represents the number of entities in the set, and t represents the upper bound (excluding t) of the number of malicious members in the DPKG committee and the lower bound (including t) of the number of honest committee members required to ensure correct protocol execution, often referred to as the threshold. Users first register with the IdP to obtain a unique identity identifier within the system, and then obtain a private key bound to their identity from the DPKG. When a user accesses the SP, the IdP issues a token to the user and sends it to the SP to prove the user's identity or attributes. Simultaneously, the IdP encrypts the token using the system's master public key and the user's identity, and submits the encryption result to the Log Server. Users use their private key bound to their identity to audit the IdP's behavior based on entries in the Log Server. SP checks the validity of tokens and the auditability of log entries, and provides corresponding services to legitimate users. IdP issues tokens to users and encrypts them, recording them in the log for user auditing and FIT forensic investigation. The log server records the encrypted user tokens and provides corresponding integrity proofs, helping users audit IdP's misconduct and providing evidence for FIT investigations. With proper authorization, FIT can decrypt tokens related to its investigation target (user) recorded in the log server with the assistance of DPKG.

[0066] The four cryptographic tools involved in this invention are defined as follows:

[0067] First, a bilinear mapping: Let For a group of order q (where q is a large prime number), define a bilinear mapping as follows: This mapping contains three properties: (i) Bilinearity: (ii) Non-degeneracy: Will not All point pairs in the map are mapped to The unit element, if g1 and g2 are respectively and The generator, then yes (iii) Computability: for any generator; and Mapping It is computable.

[0068] Second, hash function:

[0069] Third, the IBE framework includes four stages: initialization, key extraction, encryption, and decryption.

[0070] Initialization: The key generation center selects the system master private key. And set the system master public key to pk=[g,h]=[g,g sk ], g is Chinese elements.

[0071] Key extraction: Given a user ID ∈ {0,1} * The system key generation center calculates the corresponding user private key.

[0072] Encryption: Encrypt message M using the user's identity ID. Select a random number. Calculate ciphertext

[0073] Decryption: Let C = [u,v], then the process of decrypting the ciphertext from the previous step using the user's private key sk(ID) is as follows:

[0074] Fourth, (n,t) threshold secret sharing: The distributor chooses a secret s and constructs a (t-1)th order polynomial f(·) satisfying f(0) = s, for n receivers R. i (by value x) i Identifier, and x i ≠0) Calculate share i =f(x) i ), by any t receivers R i The information (x) i share i The secret s can be computed using interpolation polynomials, let's consider the set of receivers. For example, the reconstruction process is represented as follows: This example uses a finite field. The threshold secret sharing over (n,t) is the secret s, and the coefficients of the polynomial f(·) are all... Elements in the middle, operations are performed on fields Internally defined operations.

[0075] The meanings of the symbols involved in this invention are as follows:

[0076] [n]: represents the set {1,…,n};

[0077] Bilinear mapping;

[0078] q: a large prime number;

[0079] q-order group The first input group;

[0080] The second input group;

[0081] g: Generator;

[0082] The set of all elements in the remainder class modulo q;

[0083] The set of all elements in the remainder class modulo q that are relatively prime to q;

[0084] The first hash function represents a mapping.

[0085] The second hash function represents the mapping.

[0086] ID: Indicates that IdP is a unique identifier generated within the system for the user;

[0087] token: When a user accesses an SP, the IdP is an identity credential issued by the user, which includes the user's identity identifier, the SP's identity identifier, and specific token content (e.g., user attributes, issuance time, etc.).

[0088] pk: IBE framework system master public key, or simply master public key;

[0089] sk: The IBE framework system master private key, or simply master private key;

[0090] sk(ID): User ID's private key within the IBE framework;

[0091] ε(token) = [u,v]: The ciphertext obtained by encrypting the token using the user identity contained in the token;

[0092] This represents the signature of IdP for message m. This indicates the log server's signature for message m;

[0093] P i : Indicates a member of the DPKG committee;

[0094] x i : indicates P i Identification within the DPKG Committee;

[0095] s i : This indicates that when constructing the IBE framework master private key, member P i The secret of contribution;

[0096] share i,j : indicates P j Knowledge about s i The share;

[0097] Let represent the Lagrange coefficient of the i-th member in set S when calculating the interpolation at point y;

[0098] sk i : indicates member P i The share of the IBE framework master private key sk that we possess;

[0099] pk i : indicates member P i The share of the IBE framework master public key pk that we possess;

[0100] sk i (ID): Represents member P i Using sk i Calculate a portion of the ID user's private key;

[0101] bp: Represents the binding proof provided by the IdP to the SP regarding the binding relationship between the Token and the user identity contained therein;

[0102] Member P i The calculated value used to assist FIT in decrypting the token;

[0103] Log server sharding monitored by user ID.

[0104] Example 1

[0105] like Figure 1 and Figure 2 As shown in the figure, this embodiment provides a method for making single sign-on transparent and supporting ticket privacy protection, which includes the following steps:

[0106] Step 101: The distributed key generation committee generates the master public key of the identity-based encryption framework within the single sign-on system and broadcasts it within the single sign-on system; each member of the distributed key generation committee calculates the share of the master private key of the identity-based encryption framework.

[0107] Step 101 is the initialization phase, which specifically includes: initializing the threshold t of the DPKG committee. The DPKG committee uses threshold secret sharing technology to distribute and generate the IBE framework master public key within the system and broadcast it within the system. Each DPKG committee member calculates their own secret share of the IBE framework master private key and stores it locally. No single member of the distributed key generation committee can possess the complete system master private key.

[0108] A distributed key generation committee generates the master public key for the identity-based cryptographic framework within the single sign-on system and broadcasts it within the system. The committee then calculates s based on the received share of the threshold secret. i Calculating the i-th member's share of the master private key specifically includes:

[0109] For the i-th member P i Select secret value s i The system distributes secret value shares among members using a threshold secret sharing method, calculates the master public key share, and broadcasts it within the single sign-on system. More specifically, this includes: for the i-th member P... i Select secret value s i And construct a t-1 order polynomial, using Shamir threshold secret sharing to share s i The key is shared among DPKG committee members, and the corresponding partial public key pk is calculated. i Broadcast within the system.

[0110] After the broadcast of the master public key share calculated by all members of the distributed key generation committee is completed, each member in the single sign-on system uses the received master public key share (pk) to determine their status. i Calculate the master public key pk.

[0111] DPKG member P i Calculate the share sk of each individual master private key sk within the IBE framework. i .

[0112] Currently used IBE distributed key generation algorithms typically involve a reseller generating a public-private key pair, which is then secretly shared with multiple committee members. Unlike the process of generating public-private key pairs in this invention, the master private key is never held by any entity at any stage, including during the generation of the master public key and user private keys.

[0113] Step 102: The user registers their identity with an identity provider and obtains a user identity identifier generated by the identity provider. The user then sends the user identity identifier to the distributed key generation committee. The distributed key generation committee selects t members to form a first set and generates a user private key share bound to the user's identity identifier based on the master private key share corresponding to each member in the first set. After receiving the user private key share bound to the user identity identifier, the user calculates the user private key using each user private key share and verifies the correctness of the user private key using the master public key; t is a threshold value.

[0114] Since the public key has been broadcast within the system during the initialization phase, users can securely obtain the public key information. This ensures that malicious behavior by DPKG members can be detected during the generation of user private keys, guaranteeing the consistency between the user's private key and the user's identity and the system's master public key. If verification passes, the next phase proceeds; otherwise, the protocol is terminated and malicious behavior is reported to the DPKG committee.

[0115] Step 102 specifically includes:

[0116] Step 1021: During the user identity registration phase, the user initiates a registration request to the IdP, and the IdP generates a unique identity identifier ID for the user within the system.

[0117] Step 1022: The user sends their identity ID to the DPKG committee, which has t members. A set S is formed using the private key shares held by each member. Calculate the share of the user's private key. And return it to the user, i∈{1,2,…,t}, c i ∈{1,2,…,n}.

[0118] Step 1023: After receiving the shares calculated by t DPKG members, the user can use the shares to calculate their own identity private key sk(ID).

[0119] The formula for calculating a user's private key using each user's private key share is expressed as follows:

[0120]

[0121] Where sk(ID) represents the user's private key, ID represents the user's identity identifier, S represents the first set, and the number of DPKG committee members in the first set is t, c i This represents the i-th member in the first set (the member number in the DPKG committee). Represents the i-th member in the first set Using the master private key share Calculated user private key share Represents the i-th member in the first set The share of the master private key.

[0122] Step 1024: After calculating the private key sk(ID), the user verifies it using the system's public key pk. Check if the equation is true. If it is true, the user's private key is correct, and the private key sk(ID) is saved. Otherwise, if the user's private key is incorrect, terminate the protocol and report DPKG's malicious behavior.

[0123] in, This represents a bilinear mapping, where sk(ID) represents the user's private key, ID represents the user's identity identifier, and g represents... The generator in the middle is also the first component of the master public key. Let q be a group of order q, where q is a large prime number. This represents the first hash function, where h is the second component of the primary public key, and h = g. sk .

[0124] Step 103: When a user accesses a service provider, the identity provider issues a ticket to the user and generates a binding certificate that binds the ticket to the user's identity identifier. The identity provider encrypts the ticket using the user's identity identifier and master public key contained in the ticket to generate ticket ciphertext, submits the ticket ciphertext to the log server, and obtains a signed ticket timestamp issued by the log server. The identity provider sends verification information to the service provider, the verification information including the ticket, the binding certificate, the ticket ciphertext, and the signed ticket timestamp.

[0125] Step 103 is the ticket issuance stage. The binding proof demonstrates that the ε(token) verified by the SP can definitely be decrypted by the corresponding user; furthermore, it does not expose any information about other encrypted ticket ε(token') of that user. To improve efficiency, the log server is fragmented, and the encrypted ticket for the user ID is submitted to the log server. Where LogNum represents the number of shards, and H(·) represents a commonly used hash function (e.g., sha-256).

[0126] Step 103 specifically includes:

[0127] Step 1031: The user accesses the SP. The SP redirects the user's request to the IdP to authenticate the user's identity. The user completes the authentication at the IdP using the identity registered with the IdP. The IdP issues a ticket to the user for authentication at the SP.

[0128] Step 1032: The IdP encrypts the ticket to generate ciphertext ε(token) = [u,v] and the corresponding binding proof bp. The IdP signs the ciphertext ε(token) and submits it to the log server.

[0129] Step 1033: The log server verifies the IdP's signature on ε (token). If the verification is successful, an STT is generated for the ciphertext and sent to the IdP. After issuing the STT, the log server merges ε (token) into the Merkle tree within the maximum merging time.

[0130] Step 1034: IdP verifies the log server's signature on STT. If the verification is successful, {token,bp,STT} is sent to SP.

[0131] The binding proof is represented as follows:

[0132] Where bp represents the binding proof, This represents the first hash function, ID represents the user identifier, and r represents a random number;

[0133] The encrypted representation of the bill is as follows:

[0134] Where ε(token) represents the encrypted document, token represents the document, u represents the first component of the encrypted document, v represents the second component of the encrypted document, h represents the second component of the master public key, and g represents... In the middle generator, Let q be a group of order q, where q is a large prime number. ⊕ represents a bilinear mapping, and ⊕ represents the XOR operation.

[0135] Step 104: After receiving the verification information, the service provider verifies the correctness of the verification information. The conditions for the verification information to be correct are that the ticket was issued by the identity provider, the timestamp of the signed ticket was signed by the log server, and the binding proof is used to prove that the encrypted ticket is decryptable for the user to whom the encrypted ticket belongs.

[0136] Step 104 is the ticket verification stage. If the verification is successful, the service is provided to the user; otherwise, the agreement is terminated and a warning is issued to the user.

[0137] Step 104 specifically includes:

[0138] Step 1041: After receiving the {token,bp,STT} sent by the IdP, the SP first verifies whether the ticket is signed by the IdP and whether the ticket is within its validity period. If the verification is successful, proceed to the next step; otherwise, terminate the protocol and report malicious behavior.

[0139] Specifically, verifying whether the ticket was signed by the IdP includes: the SP verifying whether the signature of the ticket is correct and whether the ticket is within its validity period based on the public key information of the IdP.

[0140] Step 1042: After the ticket signature verification is successful, the SP uses the user's authentication STT signature in the ticket to check whether it is signed by the corresponding log server fragment. If the verification is successful, proceed to the next step; otherwise, stop the protocol reporting IdP for malicious behavior.

[0141] Step 1043: Verification and If both equations are true, the verification passes and the ticket is accepted; otherwise, the agreement is terminated and the user is notified of any malicious IdP behavior.

[0142] Step 105: Once the verification information is verified to be correct, the service provider successfully authenticates the user's identity and provides services to the user.

[0143] Step 106: When a user has an auditing requirement, the user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's user identity in the log server. If the decryption is successful, the decrypted ticket is audited.

[0144] If decryption is successful, the decrypted ticket will be audited. Specifically, if decryption is successful, it will be determined whether the decrypted ticket is consistent with the ticket in the user login information. If an inconsistency is detected, it will be reported that the identity provider has engaged in malicious behavior of forging user tickets.

[0145] In a specific implementation, the user or authorized party decrypts the encrypted document and checks whether the document was generated and used with the user's authorization request, in order to detect suspicious or fraudulent documents.

[0146] Step 106 is the ticket monitoring phase. In this phase, the user uses their private key to decrypt entries in the log server (user identity corresponding to the fragment). Successful decryption confirms that the ciphertext corresponds to the user's identity and can be received by the SP. Further checks are performed to determine if the ticket is fake (whether the decoded ticket matches the ticket in the user's login information). If it is fake, malicious IdP behavior is reported. Because the auditor ensures the integrity of entries in the log server, the user can find all ciphertext tickets received by the SP in the log server, ensuring that the monitoring phase can effectively detect malicious IdP behavior.

[0147] In this invention, users, digital forensics investigation teams, and judicial authorities are all participants in the single sign-on transparency process.

[0148] Step 106 specifically includes:

[0149] Step 1061: Once the auditor (SP) discovers STT during protocol execution, it requests proof of the existence of the corresponding ε (token) in the Merkle tree maintained by the log server. If the log server can provide the correct proof, it proceeds to the next step; otherwise, the auditor reports the log server's malicious behavior.

[0150] Step 1062: The monitor (user) downloads all entries from the log server (the fragment corresponding to the user's identity) and decrypts them using the user's private key. If the decryption is successful, it determines whether the ticket is a fake ticket (whether it is consistent with its own login behavior). If a fake ticket is found, it reports the malicious behavior of the IdP.

[0151] The user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's identity in the log server, which is represented as:

[0152]

[0153] Wherein, Token represents the decryption result of the encrypted document. This represents the second hash function. This represents a bilinear mapping, where sk(ID) represents the user's private key, ID represents the user's identity identifier, u represents the first component of the ciphertext of the ticket, and v represents the second component of the ciphertext of the ticket.

[0154] A form of single sign-on transparency also includes:

[0155] The sixth stage is the digital evidence collection stage. After FIT identifies the suspicious user, it applies to the judicial authorities for investigation rights for that user. After obtaining authorization, it submits the authorization information to the DPKG committee. The DPKG committee members use their respective shares of the IBE framework master private key to calculate the decryption share of the ciphertext of the ticket identified in the FIT authorization information and send the share to FIT. FIT combines the various shares and decrypts the ticket, and then uses the ticket for the subsequent evidence analysis stage.

[0156] The digital forensics investigation team sends an authorization request to the judicial authorities to conduct an investigation into the target user. The authorization includes the target user's identity information and the scope of the investigation requested by the digital forensics investigation team. The scope of the investigation includes a time frame.

[0157] After receiving the authorization application, the judicial authorities will send the authorization details of the investigation to the digital evidence investigation team.

[0158] The digital forensics investigation team sends the received authorization content to the distributed key generation committee.

[0159] After receiving the authorization message, the distributed key generation committee extracts the ciphertext of the tickets that falls within the scope of the investigation application from the log server. For each ciphertext of the tickets that falls within the scope of the investigation application, it selects t members to form a second set. Each member in the second set generates the decryption share of the target user based on their master private key share, user identity identifier, and the first component of the ciphertext of the ticket. The ciphertext of the tickets that falls within the scope of the investigation application and each of the decryption shares are then sent to the digital forensics investigation team.

[0160] For each encrypted document received that falls within the scope of the investigation application, when the digital forensics investigation team receives t decryption shares for a single encrypted document, it decrypts the document based on the encrypted document and the corresponding t decryption shares; thus obtaining each decrypted document corresponding to the target user's user identity.

[0161] The sixth stage specifically includes:

[0162] FIT first applies to judicial authorities for authorization to investigate suspicious users. This authorization includes the suspicious user's identity within the system and the scope of encrypted documents that can be investigated. After obtaining authorization, FIT sends the authorization details to the DPKG committee.

[0163] After the DPKG committee confirms the authorization is legitimate, it finds the entries contained in the authorization from the log server and selects t members for each entry. A set S is formed using the private key shares held by each member. Suspicious user identification and invoice encryption generation and decryption share And send it to FIT, i∈1,2,…,t], c i ∈[1,2,…,n], and the set S at this time does not need to be the same as that in the user registration stage.

[0164] After receiving t decryption shares, FIT combines the decryption shares to decrypt the ciphertext of the ticket and obtain the ticket information. Due to the immutable nature of the log server, the ticket information obtained after decryption has the potential to serve as legal evidence and can be used in the subsequent stages of organizing and presenting evidence during the digital forensics process.

[0165] The seventh phase is the DPKG member update phase. This phase occurs after the initialization phase and requires DPKG committee members to always meet security assumptions. It allows for the revocation of DPKG members or the allocation of secret shares of the IBE framework master key to newly joined DPKG members without updating the IBE framework master key. Specifically, it includes:

[0166] When a member of the distributed key generation committee is withdrawn (P)lapsed If, after a member's revocation, the distributed key generation committee no longer meets the security assumptions, then the single sign-on protocol is terminated. The security assumptions are that the sum of the number of malicious members and the number of revoked members in the distributed key generation committee is less than a threshold, and the number of members executing the single sign-on protocol is greater than or equal to the threshold.

[0167] Malicious members are a common definition of malicious participants in the field of cryptography, and it is a generally accepted consensus in the field of cryptography.

[0168] Regarding the various processes in this invention, malicious members can disrupt system security by actively interfering with the protocol execution process or by using information obtained during protocol execution to compute the system or the privacy information of other members within the system. Specifically, in conjunction with the protocol processes, any DPKG committee member who performs any of the following actions is considered a malicious member:

[0169] a. Conspired with other DPKG committee members to use the master private key share information they possessed to calculate privacy information within the system, such as the identity-based cryptographic framework master private key, user private keys, and ticket information.

[0170] b. During the initialization phase, the protocol is not executed or is executed incorrectly, such as failing to distribute or incorrectly distributing the broadcast master public key share, failing to execute or incorrectly performing threshold secret sharing of the secret value, etc.

[0171] c. Selected to form the first set during the user registration phase, but fails to execute or incorrectly executes the protocol, such as refusing to send or sending the wrong user private key share.

[0172] d. Selected to form a second set during the digital evidence collection phase, but fails to perform or incorrectly performs the protocol, such as refusing to send or sending the wrong decryption share.

[0173] e. During the member update phase of the distributed key generation committee, the protocol is not executed or is executed incorrectly, such as refusing to send the secret value share of the revoked member to the newly joined member or sending the wrong secret value share of the revoked member.

[0174] The Single Sign-On protocol includes the processes for each member in steps 101-106.

[0175] When a member is removed, a new member P is added. new When applying to join the Distributed Key Generation Committee, the new member submits a membership application to the Distributed Key Generation Committee, and each member of the Distributed Key Generation Committee sends the secret value share of the currently revoked member to the new member.

[0176] When a new member receives t shares of secret value, the secret value used by the current revoked member to calculate the master private key is obtained by interpolation based on the t shares of secret value. The new member uses the secret value used by the current revoked member to calculate the master private key as its own secret value, where t is a positive integer greater than 1.

[0177] The specific operational flow of the single sign-on transparency method supporting ticket privacy protection according to the present invention includes:

[0178] Phase 1: Initialization Phase

[0179] a) The system selects the DPKG committee threshold t. t is a given positive integer.

[0180] b) P members of DPKG i Select secret value And using the (n,t) threshold secret sharing method to share s i Among DPKG members (including P) i Secret sharing and computation between them. And broadcast it within the system.

[0181] Among them, h i This indicates that DPKG member P i Selected secret value s i The computation share corresponding to the public key pk = [g, h] used to compute the system master public key.

[0182] c) Members in the system use the PK broadcast in the previous step... i Calculate the IBE framework master public key Each DPKG member P i Using the share obtained in the previous step *,i (P i Received about s * The share of the IBE framework master private key is calculated.

[0183] Phase Two: User Registration Phase

[0184] like Figure 3 As shown, the user registration phase includes the following steps.

[0185] a) The user initiates a registration request to the IdP, and the IdP generates a unique identity identifier (ID) for the user within the system.

[0186] b) The user sends their identity ID to the DPKG committee, which has t members. A set S is formed using the private key shares held by each member. Calculate the share of the user's private key. And return it to the user, i∈[1,2,…,t], c i ∈[1,2,…,n], where t is the threshold and n is the number of members in the DPKG.

[0187] c) After receiving t shares calculated by DPKG members, the user can use these shares to calculate their own identity private key.

[0188] d) After calculating the private key sk(ID), the user verifies the equation using the system's public key pk. If successful, the private key sk(ID) is saved; otherwise, the protocol is terminated and malicious behavior of DPKG is reported.

[0189] Phase Three: Bill Issuance Phase

[0190] like Figure 4 As shown, the bill issuance stage includes the following steps.

[0191] a) When a user accesses an SP, the SP redirects the user's request to an IdP to verify the user's identity. The user then completes authentication at the IdP using the identity registered with the IdP. The IdP issues a token to the user for authentication at the SP.

[0192] b) IdP selects a random number r, and uses the identity ID to encrypt the token to generate ciphertext. and corresponding binding proof IdP signs the ciphertext ε (token) and... Submit to the log server.

[0193] This indicates that the IdP has signed the encrypted token.

[0194] c) Log server verification The signature, if verified, generates ε(token). It is then sent to IdP, and the log server merges ε(token) into the Merkle tree within the maximum merge time after issuing STT.

[0195] d) IdP verification The signature, if verified, will be Send to SP.

[0196] Phase Four: Invoice Verification Phase

[0197] like Figure 5 As shown, the document verification stage includes the following steps.

[0198] a) After receiving {token,bp,STT} from IdP, SP first verifies whether the token is signed by IdP. If the verification is successful, it proceeds to the next step; otherwise, it terminates the protocol and reports malicious behavior.

[0199] b) After the token signature verification is successful, the SP uses the user's identity in the ticket to calculate... And utilize log server sharding The public key is used to verify whether the STT signature is correct. If the verification is successful, proceed to the next step; otherwise, the protocol is terminated and IdP is reported for malicious behavior.

[0200] c) Verification and If the verification is successful, the ticket is accepted; otherwise, the agreement is terminated and the user is notified of any malicious IdP activity.

[0201] Phase 5: Bill Monitoring Phase

[0202] like Figure 6 As shown, the bill monitoring phase includes the following steps.

[0203] a) Once the auditer (SP) discovers an STT during protocol execution, it requests proof of the existence of the corresponding ε (token) in the Merkle tree maintained by the log server. If the log server can provide the correct proof, it proceeds to the next step; otherwise, the auditer reports the log server for malicious behavior.

[0204] a) The monitor (user) downloads all entries (i.e., ciphertext, entry = C = [u, v]) from the log server (the fragment corresponding to the user's identity) and decrypts them. If decryption is successful, it will determine whether M is a fake token (inconsistent with its own login behavior). If a fake token is found, it will report the malicious behavior of IdP.

[0205] Phase Six: Digital Evidence Collection Phase

[0206] b) FIT first applies to the judicial authorities for authorization to investigate suspicious users. The authorization includes the suspicious user's identity ID in the system and the permitted log recording time range. After obtaining authorization, FIT sends the authorization to the DPKG committee.

[0207] c) After the DPKG committee confirms the authorization is valid, it finds the entries (entry = ε(token)) within the authorized time range from the log server, and selects t members for each entry. A set S is formed using the private key shares held by each member. Calculate decryption share And send it to FIT, i∈[t], ci For each entry ∈[n], the set S does not need to be the same as the one used during the user registration phase. Furthermore, for simplicity, the set S corresponding to each entry can also be the same.

[0208] d) For each encrypted note within the authorized scope, after FIT receives t decryption shares, it combines the decryption shares to decrypt the encrypted note and obtain the note information. Due to the immutable nature of log servers, the decrypted ticket information has the potential to serve as legal evidence and can be used in the subsequent stages of organizing and presenting evidence during the digital forensics process.

[0209] To further illustrate the security nature of the technical solution in this invention, the following security assumptions are given: (1) Users and SPs honestly execute the protocol process; (2) IdP and log server may issue false tickets or STTs due to malice or being attacked; (3) The sum of the number of malicious members in the DPKG committee and the number of revoked DPKG committee members is less than t, and the number of members honestly executing the protocol is at least t, where t is a threshold; (4) Off-system attackers (passive attackers), malicious members in the DPKG committee, SPs, log servers, users, SPs, and FITs all attempt to obtain more private information.

[0210] Phase 7: DPKG Member Replacement Phase

[0211] a) Withdraw member P lapsed First, determine member P. lapsed If the DPKG committee members meet the security assumptions after the withdrawal, the agreement will be withdrawn directly; otherwise, it will be terminated.

[0212] b) When a new entity P is created after the cancellation. new When applying to join the DPKG Committee, an application is submitted to the DPKG Committee, and each member of the DPKG Committee, P i Send share lapsed,i To P new .

[0213] c) When the received share lapsed,i When the number of values ​​reaches t, these t values ​​come from P new Able to interpolate P lapsed The secret value chosen when calculating the master private key And use it as its own secret value. At this time, the set S does not need to be the same as the user registration stage and the digital evidence stage.

[0214] DPKG committee members execute the initialization protocol using the secret values ​​they currently possess.

[0215] This invention addresses the issue of IdP (In-Depth Point of Sale) failure by introducing transparency into existing single sign-on (SSO) systems. To protect user privacy, user tickets are encrypted using the IBE (In-Behind-the-Air) framework before being submitted to a log server. Users can detect malicious IdP behavior through the log server without third-party intervention. No centralized trusted entity is assumed in the system. This invention also provides a method for digital forensics of user behavior within a SSO system, ensuring the integrity of the evidence.

[0216] The security objectives to be achieved by this invention include: (1) Transparency: First, any malicious behavior of the IdP will be monitored by stakeholders (e.g., users); second, the FIT with legitimate authorization has the ability to investigate the access history of a specific user; (2) Privacy: No entity other than the user and the FIT can obtain additional privacy information based on the entries recorded in the log server, and the FIT can only decrypt entries within its authorized scope, while the user can only decrypt entries bound to their identity and verified by the SP. For entries that cannot be decrypted, attackers cannot establish connections between different entries or between entries and users; (3) Distributed trust: This invention does not assume a centralized trusted entity. The DPKG establishes the IBE framework in a distributed manner in a committee manner, and the behavior of the IdP is auditable by the user.

[0217] The following explains the reasons for achieving the security objectives:

[0218] Regarding transparency:

[0219] a) Since the security assumption assumes that the SP honestly executes the protocol, all tickets received by the SP simultaneously satisfy (1) issued by the IdP; (2) submitted by the IdP to the log server (the fragment corresponding to the user identity) and obtain STT; (3) the ciphertext ε (token) submitted by the IdP satisfies: and The system employs several mechanisms: First, verifying the IdP's signature ensures that any counterfeit tickets originate from an erroneous IdP issuance. Second, verifying the STT ensures that the IdP submits ε(token) to the log server. The presence of an auditor guarantees the log server's records are immutable, and all observed STT-corresponding ciphertexts are added to the log server's records. This ensures that even if the log server helps the IdP conceal malicious behavior, it can still be detected by the auditor and the user. Therefore, if the log server's behavior is compliant, and a counterfeit ticket issued by the IdP is received by the SP, the ciphertext of that ticket will definitely be recorded in the log server. Third, verifying that ε(token) satisfies two equations utilizes the bilinear mapping property: if a ticket is received by the SP, the ciphertext recorded in the log server, decrypted using the user's private key, will match the ticket information observed by the SP. In summary, users can observe all ticket information received by the SP based on the log server's records, and thus, combined with their login history, determine whether the IdP has engaged in malicious behavior by issuing counterfeit tickets.

[0220] (b) As known from the above (a), the ciphertext of all tickets received by the SP is recorded in the log server, and the integrity of the records is guaranteed by the auditor. Therefore, it is sufficient to prove that FIT has digital forensics capabilities by ensuring that FIT can decrypt the ciphertext of suspicious users' tickets. Since there are always t or more DPKG members honestly executing the protocol in the security assumption, and any t members in the DPKG committee can calculate keys for users, it can be assumed that t or more DPKG members have decryption capabilities equivalent to any user in the system. Therefore, with the help of the DPKG committee, FIT can decrypt the tickets of any suspicious user within the authorized scope, thereby completing the forensics process, and the evidence is complete.

[0221] Regarding privacy:

[0222] a) When attackers (e.g., external eavesdroppers, log servers, and users who are not the ticket owner) can only obtain public information (e.g., the IBE framework master public key, records in the log server), such attackers cannot obtain additional private information because the IBE framework used is semantically secure.

[0223] b) When an attacker (e.g., SP) is able to obtain a portion of the ticket and the corresponding binding proof through the protocol, the attacker cannot obtain additional privacy information from the binding proof because the only privacy information contained in the binding proof is the random number r selected during IdP encryption. Since the selection of the random number should be independent each time IdP is encrypted, the attacker cannot obtain additional privacy information from the binding proof. Furthermore, due to the semantic security of the IBE framework, the portion of the ticket held by the attacker will not affect the privacy of the remaining tickets. Therefore, it can be considered that for the unobtained tickets, such an attacker has the same attack capability as the attacker described in a.

[0224] c) When an attacker (FIT and fewer than t curious DPKG members) can obtain public information and partially decrypted tickets, due to the independence of each encryption execution of IdP and the characteristics of the secret-sharing scheme, the attacker cannot obtain any information about the distributed generation secret of the DPKG system (IBE framework master private key and each user's private key). As known from the analysis of the attacker's capabilities in b, the tickets held by the attacker will not affect the privacy of the remaining tickets. Therefore, it can be considered that for tickets that have not been obtained, such an attacker has the same attack capabilities as the attacker described in a.

[0225] Regarding distributed trust, this solution primarily addresses the centralized trust issue of IdPs by using a log server to record tickets and a monitor to audit IdP behavior, thus avoiding centralized trust. Secondly, the IBE framework is established in a distributed manner by the DPKG committee, avoiding centralized reliance on a single entity. Finally, the log server is audited by an auditor to ensure the integrity of log server records.

[0226] Example 2

[0227] This embodiment provides a single sign-on transparency system that supports ticket privacy protection, including: a distributed key generation committee, users, identity providers, and service providers.

[0228] The distributed key generation committee is used to generate the master public key of the identity-based encryption framework within the single sign-on system in a distributed manner, and broadcast it within the single sign-on system; each member of the distributed key generation committee calculates the share of the master private key of the identity-based encryption framework.

[0229] The user registers their identity with an identity provider and obtains a user identity identifier generated by the identity provider. The user then sends the user identity identifier to the distributed key generation committee. The distributed key generation committee selects t members to form a first set and generates a user private key share bound to the user's identity identifier based on the master private key share corresponding to each member in the first set. After receiving the user private key share bound to the user identity identifier, the user calculates the user private key using each user private key share and verifies the correctness of the user private key using the master public key.

[0230] When a user accesses a service provider, the identity provider issues a ticket to the user and generates a binding certificate that links the ticket to the user's identity identifier. The identity provider encrypts the ticket using the user's identity identifier and master public key contained in the ticket to generate ciphertext, submits the ciphertext to a log server, and obtains a signed ticket timestamp issued by the log server. The identity provider then sends verification information to the service provider, which includes the ticket, the binding certificate, the ciphertext, and the signed ticket timestamp.

[0231] The service provider, upon receiving the verification information, verifies the correctness of the verification information. The conditions for the verification information to be correct are that the ticket is issued by the identity provider, the timestamp of the signed ticket is signed by the log server, and the binding proof proves that the encrypted ticket is decryptable for the user to whom the encrypted ticket belongs.

[0232] Once the verification information is verified to be correct, the service provider successfully authenticates the user's identity and provides services to the user.

[0233] When a user has an auditing requirement, the user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's user identity in the log server. If the decryption is successful, the decrypted ticket is audited.

[0234] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0235] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for achieving transparent single sign-on that supports ticket privacy protection, characterized in that, include: The distributed key generation committee generates the master public key of the identity-based encryption framework within the single sign-on system and broadcasts it within the single sign-on system. Each member of the distributed key generation committee calculates the master private key share of the identity-based cryptographic framework. Users register their identity with an identity provider and obtain a user identity identifier generated by the identity provider. The user then sends this user identity identifier to the distributed key generation committee; the distributed key generation committee selects... t The first set consists of several members. Based on the master private key share corresponding to each member in the first set, a user private key share bound to the user identity is generated for the user. After receiving the user private key share bound to the user identity, the user calculates the user private key using each user private key share and verifies the correctness of the user private key using the master public key. t For the threshold; When a user accesses a service provider, the identity provider issues a ticket to the user and generates a binding certificate that links the ticket to the user's identity identifier. The identity provider encrypts the ticket using the user's identity identifier and master public key contained in the ticket, generates ticket ciphertext, submits the ticket ciphertext to a log server, and obtains a signed ticket timestamp issued by the log server. The identity provider then sends verification information to the service provider, which includes the ticket, the binding certificate, the ticket ciphertext, and the signed ticket timestamp. After receiving the verification information, the service provider verifies the correctness of the verification information. The conditions for the verification information to be correct are that the ticket was issued by the identity provider, the timestamp of the signed ticket was signed by the log server, and the binding proof proves that the encrypted ticket is decryptable for the user to whom the encrypted ticket belongs. Once the verification information is verified to be correct, the service provider successfully authenticates the user's identity and provides services to the user. When a user has an auditing requirement, the user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's user identity in the log server. If the decryption is successful, the decrypted ticket is audited.

2. The single sign-on transparency method supporting ticket privacy protection according to claim 1, characterized in that, A distributed key generation committee generates the master public key for the identity-based cryptographic framework within the single sign-on system and broadcasts it within the single sign-on system, specifically including: Each member of the distributed key generation committee selects a secret value and shares it among themselves using a threshold secret sharing method. At the same time, they calculate the share of the master public key based on the secret value and broadcast it within the single sign-on system. After all the secret values ​​selected by the members of the distributed key generation committee have been shared, each member calculates their share of the master private key based on the received share of the threshold secret shared secret value. Once all members of the distributed key generation committee have broadcast their calculated public key shares, each member in the single sign-on system calculates their public key based on the received public key shares.

3. The single sign-on transparency method supporting ticket privacy protection according to claim 2, characterized in that, When a member of the distributed key generation committee is revoked, if the distributed key generation committee does not meet the security assumptions after the member is revoked, the single sign-on protocol is terminated. The security assumptions are that the sum of the number of malicious members and the number of revoked members in the distributed key generation committee is less than a threshold, and the number of members executing the single sign-on protocol is greater than or equal to the threshold. When a member is revoked and a new member applies to join the distributed key generation committee, the new member submits a membership application to the distributed key generation committee, and each member of the distributed key generation committee sends the secret value share of the revoked member to the new member. When the share of secret value received by new members reaches t At that time, according to t Each secret value share is interpolated to obtain the secret value used by the currently revoked member when calculating the master private key. The new member uses the secret value used by the currently revoked member when calculating the master private key as their own secret value.

4. The single sign-on transparency method supporting ticket privacy protection according to claim 1, characterized in that, The formula for calculating a user's private key using each user's private key share is expressed as follows: in, This represents the user's private key. Indicates user identity identifier, S Represents the first set, S The number of members is greater than the threshold. In the first set, the first... i The member number of each member in the distributed key generation identity committee. In the first set, the first... i Individual members used The calculated share of the user's private key. In the first set, the first... i Each member's share of the master private key.

5. The single sign-on transparency method supporting ticket privacy protection according to claim 1, characterized in that, Verifying the correctness of the user's private key using the master public key specifically includes: Verify the equation Is it valid? If so, then the user's private key is correct; If not, the user's private key is incorrect, and the user shall issue a report of malicious behavior by the distributed key generation committee. in, Represents a bilinear mapping. This represents the user's private key. Indicates user identity identifier, express In the middle generator, express The second input group, Indicates the first hash function, h = , This represents the master private key.

6. The method for achieving transparent single sign-on with support for ticket privacy protection according to claim 1, characterized in that, The binding proof is represented as follows: ; in, This indicates the binding proof. Indicates the first hash function, Indicates user identity identifier, r express Random numbers in the data; The encrypted representation of the bill is as follows: ; in, This indicates the encrypted message of the document. This represents the first component of the encrypted document. This represents the second component of the encrypted document. h = , Indicates the master private key. express In the middle generator, express The second input group, Modulus All remaining classes with A set of coprime elements. For large prime numbers, Represents a bilinear mapping. This represents the second hash function.

7. The single sign-on transparency method supporting ticket privacy protection according to claim 1, characterized in that, The user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's identity in the log server, which is represented as: ； in, This indicates the decryption result of the encrypted document. This represents the second hash function. Represents a bilinear mapping. This represents the user's private key. Indicates user identity identifier, This represents the first component of the encrypted document. This represents the second component of the encrypted document.

8. The method for achieving transparent single sign-on with support for ticket privacy protection according to claim 1, characterized in that, Also includes: Once the verification information is verified as correct, when a user has an auditing requirement, the user uses their private key to decrypt the ciphertext of the ticket corresponding to their user identity in the log server. If decryption is successful, the decrypted ticket is audited, specifically including: If decryption is successful, it is determined whether the decrypted ticket matches the ticket in the user's login information. If an inconsistency is detected, it is reported that the identity provider has engaged in malicious behavior of forging user tickets.

9. The method for achieving transparent single sign-on with support for ticket privacy protection according to claim 1, characterized in that, Also includes: The digital forensics investigation team sends an authorization application to the judicial authorities to conduct an investigation on the target user. The authorization includes the user's identity identifier and the scope of the investigation requested by the digital forensics investigation team. After receiving the authorization application, the judicial authorities will send the authorization content of the investigation to the digital evidence investigation team; The digital forensics investigation team sends the received authorization content to the distributed key generation committee; After receiving the authorization content, the distributed key generation committee extracts the ciphertext of the tickets that falls within the scope of the investigation request from the log server. For each ciphertext of the tickets that falls within the scope of the investigation request, it selects... t The second set consists of several members. Each member in the second set generates the decryption share of the target user based on their own master private key share and the first component of the ciphertext of the bill. The ciphertext of the bill that meets the scope of the investigation application and each of the decryption shares are sent to the digital forensics investigation team. For each encrypted document received that falls within the scope of the investigation application, when the digital forensics investigation team receives information regarding an encrypted document... t After decrypting the specified share, based on the ciphertext of the bill and the corresponding ciphertext... t The decryption unit decrypts the ticket; Obtain the decrypted tickets corresponding to the user identity identifier of the target user.

10. A single sign-on transparency system supporting ticket privacy protection, characterized in that, include: Distributed key generation committees, users, identity providers, and service providers; The distributed key generation committee is used to generate the master public key of the identity-based encryption framework within the single sign-on system in a distributed manner, and broadcast it within the single sign-on system; each member of the distributed key generation committee calculates the master private key share of the identity-based encryption framework. Users register their identity with an identity provider to obtain a user identity identifier generated by the identity provider, and then send the user identity identifier to the distributed key generation committee; the distributed key generation committee selects... t The first set consists of several members. Based on the master private key share corresponding to each member in the first set, a user private key share bound to the user identity is generated for the user. After receiving the user private key share bound to the user identity, the user calculates the user private key using each user private key share and verifies the correctness of the user private key using the master public key. When a user accesses a service provider, the identity provider issues a ticket to the user and generates a binding certificate that links the ticket to the user's identity identifier. The identity provider encrypts the ticket using the user's identity identifier and master public key contained in the ticket to generate ciphertext, submits the ciphertext to a log server, and obtains a signed ticket timestamp issued by the log server. The identity provider then sends verification information to the service provider, which includes the ticket, the binding certificate, the ciphertext, and the signed ticket timestamp. The service provider is used to verify the correctness of the verification information after receiving it. The conditions for the verification information to be correct are that the ticket is issued by the identity provider, the timestamp of the signed ticket is signed by the log server, and the binding proof is used to prove that the encrypted ticket is decryptable for the user to whom the encrypted ticket belongs. Once the verification information is verified to be correct, the service provider successfully authenticates the user's identity and provides services to the user. When a user has an auditing requirement, the user uses the user's private key to decrypt the ciphertext of the ticket corresponding to the user's user identity in the log server. If the decryption is successful, the decrypted ticket is audited.

Images