Local Encryption Key Splitting for SSO Data Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Single Sign-On (SSO) systems face a security flaw in securely generating and storing encryption keys for client-side application data when users log in via an external authentication source, as the client-side portion cannot generate encryption keys due to lack of access to user passwords.
Innovation Solution
The client-side application generates a random encryption key, divides it into shares using a secret sharing algorithm, and stores one share securely with a trusted third party, allowing decryption upon successful authentication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If SSO system is implemented to allow single sign-on access, then ease of operation is improved, but security of client-side application data is worsened
Solution Approach 1:
The encryption key is divided into multiple shares using secret sharing algorithms, where no single share can reconstruct the key alone. This segments the security credential so that even though SSO provides centralized authentication, the actual decryption capability is distributed and requires collaboration between multiple parties (cloud service and trusted third party), thus maintaining security while enabling SSO convenience
Solution Approach 2:
A trusted third party is introduced as an intermediary to hold one share of the encryption key. This intermediary enables the SSO system to function by verifying authentication tokens and releasing the necessary key share to the client device, without the trusted third party having access to the complete encryption key or being able to decrypt the data alone
2Ease of operation
If encryption key is derived from user password, then ease of operation is improved, but adaptability is worsened
Solution Approach 1:
Instead of deriving the encryption key from the user password (traditional approach), the system inverts the approach by using the authenticated token from the external authentication source combined with a share from the trusted third party to reconstruct the encryption key. This allows the system to work with external authentication sources while maintaining strong encryption
Solution Approach 2:
The system changes the input parameters for key derivation from user password to authenticated token plus trusted third party share. This parameter change enables compatibility with external authentication sources like SSO systems while maintaining the security properties of password-based encryption through the use of cryptographically strong tokens
Data Source
AI summary
The present disclosure describes techniques that allow for a client-side application, located on a first client device, to generate a random encryption key and encrypt locally-stored application data with the random encryption key. In order to ensure that the client-device application is unable to decrypt the locally-stored encrypted application data prior to authenticating with an external authentication source (i.e., SSO, IdP), the client-side application divides the random encryption key into at least a first share and a second share according to a secret sharing algorithm. The first share is transmitted to a trusted third party, while the second share is encrypted locally and stored in a secure location on the client device. Upon successful authentication, the trusted third party returns the second share to the first client device. The client-side application derives the random encryption key and decrypts the locally-stored encrypted application data to be used by the client-side application. By dividing the key used to encrypt the client-side application data and storing one of the secret shares necessary to deriving the key at a trusted third party, the present disclosure solves the problem of how to encrypt local application data when the login credentials for the application are managed by a trusted third party, such as an SSO system.