Security case study
A breach should not reveal the documents.
iQabinet was built for financial, medical, and household records. Encrypting the database was only the starting point.
The security goal
Stealing one database, storage bucket, credential, or key fragment should not be enough to read a customer's files. The system divided the information needed for decryption instead of keeping one complete key in one place.
The model
Separate the paths to the data.
TenUp helped turn the split-key design into a shared cryptography layer used across the application.
- 01
Protect the private key
Each user received an RSA private key secured by their password.
- 02
Split the credential
The decryption path required separate user-held and system-held material.
- 03
Encrypt the records
AES handled the repeated encryption and decryption of user data and files.
- 04
Apply it everywhere
One cryptography layer covered writes and reads across MongoDB, PostgreSQL, and S3.
What it changed
No single stored secret was supposed to unlock a family's records.
That is the concrete idea behind reducing what a user has to trust. A customer did not have to assume that one database, storage system, administrator account, or credential would remain perfect forever.
This page summarizes the implementation account published by TenUp Software. Security descriptions are historical architecture claims, not a current audit or certification.
Read the original TenUp case study ↗