Multi-Party SSO Key Segmentation in Zero-Knowledge Architecture
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Implementing Single-Sign-On (SSO) authentication in a zero-knowledge architecture poses challenges, particularly in deriving a secret key for encrypting and decrypting user data, as identity providers do not provide key material, and relying parties may introduce security vulnerabilities if compromised.
Innovation Solution
A system involving multiple relying parties and identity providers, where each party holds a part of a secret key, which is combined by the user device to generate a final secret key for decrypting user data, ensuring security even if one party is compromised, and allowing untrusted third parties to operate these parties without exposing the full key.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single relying party is used to provide secret key material for SSO authentication, then the authentication process is simple, but the security is compromised if the relying party is breached
Solution Approach 1:
The secret key material is segmented into multiple parts (first part, second part, etc.) and distributed to different relying parties. Each relying party holds only a portion of the secret key, so that compromise of one party does not expose the entire secret key. The user device combines these parts to reconstruct the full secret key for authentication.
Solution Approach 2:
The user device acts as an intermediary that collects secret key parts from multiple relying parties and combines them to form the complete secret key. This intermediary role allows the system to distribute security responsibilities while maintaining a centralized point for key reconstruction and authentication management.
2Reliability
If multiple relying parties are used to hold parts of the secret key, then security is improved, but the authentication process becomes more complex
Solution Approach 1:
The authentication system is designed to work with any number of relying parties through a universal interface. The user device follows a standardized process of requesting secret key parts from multiple relying parties and combining them, making the system adaptable to different numbers of parties without requiring fundamental changes to the authentication flow.
Solution Approach 2:
The user device autonomously manages the collection and combination of secret key parts from multiple relying parties without requiring manual intervention. The system automatically requests, receives, and combines the key parts, reducing the operational burden on users despite the involvement of multiple parties.
3Ease of operation
If identity providers provide authentication, then user convenience is improved, but they cannot provide key material for encryption
Solution Approach 1:
The functionality for providing secret key material is extracted from the identity providers and assigned to separate relying parties. Identity providers focus solely on authentication, while relying parties are responsible for holding and providing portions of the secret key. This separation allows each component to specialize in its intended function.
Solution Approach 2:
The system adds a new dimension to the authentication architecture by introducing relying parties as a separate layer between identity providers and the user device. This dimensional addition enables the system to simultaneously achieve authentication (from identity providers) and secret key provision (from relying parties) without compromising either function.
Data Source
AI summary
A system and method for providing secure Single-Sign-On (SSO) authentication in a zero-knowledge architecture. A first server component may operate as a first relying party in a first SSO flow. When the user of an application successfully authenticates to a first identity provider, a first part of a secret key may be provided to the application. Additionally, a second server component may operate as a second relying party in a second SSO flow. When the first part of the secret key is received by the application, authentication information may be provided to a second identity provider. Based on a successful authentication, a second part of the secret key may be provided to the application. The first and second parts of the secret key may be combined by the application to generate a final secret key that may be used to decipher encrypted user data.